Private methods

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Private methods

Jeff Gray
Coming from doing a lot of java and C#, a lot of my classes' internal processing would be done with private methods.
Is there a similar mechanism in smalltalk?
I suspect I may be thinking about this all wrong :-)
 
Reply | Threaded
Open this post in threaded view
|

Re: Private methods

Alan Rodas
Private methods don't exist in Smalltalk. Every method is exposed as public, and anyone can call it, from anywhere.
As you can select a protocol for your methods to arrange them under a name or category, you may use the "private" category. This indicates to the users that a method is private, and should not be called from outside the class.
As oposite, every instance variable is protected, and it can be seen just from the class and its subclases. If you want to expose a variable, you need to create accessors.

Hope this helps you. C Ya
--
Alan Rodas Bonjour


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Private methods

eMko
There is a convention of naming private methods - instead of naming it just "methodName" you can use "myMethodName".

I have seen this convention in some tutorials at squeak wiki but have not seen a system class in squeak or pharo which uses this. But I do in my programs. A different naming convention of private/protected methods is quite common in other programming or scripting languages like Perl, Python, PHP ...
Reply | Threaded
Open this post in threaded view
|

Re: Private methods

Tobias Pape
Hi

Am 2010-11-02 um 10:24 schrieb eMko:
> There is a convention of naming private methods - instead of naming it just
> "methodName" you can use "myMethodName".
>
> I have seen this convention in some tutorials at squeak wiki but have not
> seen a system class in squeak or pharo which uses this. But I do in my
> programs. A different naming convention of private/protected methods is
> quite common in other programming or scripting languages like Perl, Python,
> PHP ...

Incidentally, if you name your method "pvtMethodName" it is expected that
this message is only sent to self.

So if you have a class
"--"
Object subclass: #Foobar
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'TMP'
"--"

with
Foobar>>pvtTest

        Transcript show: 'Foobar'.

and then do

| a |
a := Foobar new.
a pvtTest.

you'll end up with the Compiler telling you
that “Private messages may only be sent to self”.

However, according to Smalltalk conventions, you should
use these “private” methods scarcely. In fact, it is easy to
circumvent this check:

| a |
a := Foobar new.
a  perform: #pvtTest a Foobar

works easily, so don't rely on the privateness. However,
whatever one sends to your object is up to her/him and
she/he is responsible for the outcome ;)

HTH

So Long,
        -Tobias
_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Private methods

Stéphane Ducasse
In reply to this post by eMko
I removed that in pharo since it was a hack working only on squeak and not even well because what happens if
I do an alias to self

        obj := self.

        obj pvt....

or with passing a ref to me around and client invoke the method.

aA foo: self

A>>foo: aA

        aA pvt

For people that want to read a nice paper on private methods I suggest:
        Encapsulation in a dynamic language by nathanael scharly
                => only self send (using self keywords could be potential private call) I like the idea and the reasoning behind.

        and freezable traits to a certain extent


Stef

>
> Hi
>
> Am 2010-11-02 um 10:24 schrieb eMko:
>> There is a convention of naming private methods - instead of naming it just
>> "methodName" you can use "myMethodName".
>>
>> I have seen this convention in some tutorials at squeak wiki but have not
>> seen a system class in squeak or pharo which uses this. But I do in my
>> programs. A different naming convention of private/protected methods is
>> quite common in other programming or scripting languages like Perl, Python,
>> PHP ...
>
> Incidentally, if you name your method "pvtMethodName" it is expected that
> this message is only sent to self.
>
> So if you have a class
> "--"
> Object subclass: #Foobar
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'TMP'
> "--"
>
> with
> Foobar>>pvtTest
>
> Transcript show: 'Foobar'.
>
> and then do
>
> | a |
> a := Foobar new.
> a pvtTest.
>
> you'll end up with the Compiler telling you
> that “Private messages may only be sent to self”.
>
> However, according to Smalltalk conventions, you should
> use these “private” methods scarcely. In fact, it is easy to
> circumvent this check:
>
> | a |
> a := Foobar new.
> a  perform: #pvtTest a Foobar
>
> works easily, so don't rely on the privateness. However,
> whatever one sends to your object is up to her/him and
> she/he is responsible for the outcome ;)
>
> HTH
>
> So Long,
> -Tobias
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Private methods

Igor Stasenko
Coding in smalltalk for last 4 years, i seen no problems with having
no run-time, no compile-time , but instead a coder-time private methods check.

As to me, the benefits of having such constraints in language are exaggerated.

On 3 November 2010 01:34, Stéphane Ducasse <[hidden email]> wrote:

> I removed that in pharo since it was a hack working only on squeak and not even well because what happens if
> I do an alias to self
>
>        obj := self.
>
>        obj pvt....
>
> or with passing a ref to me around and client invoke the method.
>
> aA foo: self
>
> A>>foo: aA
>
>        aA pvt
>
> For people that want to read a nice paper on private methods I suggest:
>        Encapsulation in a dynamic language by nathanael scharly
>                => only self send (using self keywords could be potential private call) I like the idea and the reasoning behind.
>
>        and freezable traits to a certain extent
>
>
> Stef
>
>>
>> Hi
>>
>> Am 2010-11-02 um 10:24 schrieb eMko:
>>> There is a convention of naming private methods - instead of naming it just
>>> "methodName" you can use "myMethodName".
>>>
>>> I have seen this convention in some tutorials at squeak wiki but have not
>>> seen a system class in squeak or pharo which uses this. But I do in my
>>> programs. A different naming convention of private/protected methods is
>>> quite common in other programming or scripting languages like Perl, Python,
>>> PHP ...
>>
>> Incidentally, if you name your method "pvtMethodName" it is expected that
>> this message is only sent to self.
>>
>> So if you have a class
>> "--"
>> Object subclass: #Foobar
>>       instanceVariableNames: ''
>>       classVariableNames: ''
>>       poolDictionaries: ''
>>       category: 'TMP'
>> "--"
>>
>> with
>> Foobar>>pvtTest
>>
>>       Transcript show: 'Foobar'.
>>
>> and then do
>>
>> | a |
>> a := Foobar new.
>> a pvtTest.
>>
>> you'll end up with the Compiler telling you
>> that “Private messages may only be sent to self”.
>>
>> However, according to Smalltalk conventions, you should
>> use these “private” methods scarcely. In fact, it is easy to
>> circumvent this check:
>>
>> | a |
>> a := Foobar new.
>> a  perform: #pvtTest a Foobar
>>
>> works easily, so don't rely on the privateness. However,
>> whatever one sends to your object is up to her/him and
>> she/he is responsible for the outcome ;)
>>
>> HTH
>>
>> So Long,
>>       -Tobias
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Private methods

Simon Denier-3
In reply to this post by Stéphane Ducasse

On 3 nov. 2010, at 05:47, Igor Stasenko wrote:

> Coding in smalltalk for last 4 years, i seen no problems with having
> no run-time, no compile-time , but instead a coder-time private methods check.
>
> As to me, the benefits of having such constraints in language are exaggerated.


Indeed, for such rules, I think Lint should be the platform of choice (using the parse tree search if necessary).


>
> On 3 November 2010 01:34, Stéphane Ducasse <[hidden email]> wrote:
>> I removed that in pharo since it was a hack working only on squeak and not even well because what happens if
>> I do an alias to self
>>
>>        obj := self.
>>
>>        obj pvt....
>>
>> or with passing a ref to me around and client invoke the method.
>>
>> aA foo: self
>>
>> A>>foo: aA
>>
>>        aA pvt
>>
>> For people that want to read a nice paper on private methods I suggest:
>>        Encapsulation in a dynamic language by nathanael scharly
>>                => only self send (using self keywords could be potential private call) I like the idea and the reasoning behind.
>>
>>        and freezable traits to a certain extent
>>
>>
>> Stef
>>
>>>
>>> Hi
>>>
>>> Am 2010-11-02 um 10:24 schrieb eMko:
>>>> There is a convention of naming private methods - instead of naming it just
>>>> "methodName" you can use "myMethodName".
>>>>
>>>> I have seen this convention in some tutorials at squeak wiki but have not
>>>> seen a system class in squeak or pharo which uses this. But I do in my
>>>> programs. A different naming convention of private/protected methods is
>>>> quite common in other programming or scripting languages like Perl, Python,
>>>> PHP ...
>>>
>>> Incidentally, if you name your method "pvtMethodName" it is expected that
>>> this message is only sent to self.
>>>
>>> So if you have a class
>>> "--"
>>> Object subclass: #Foobar
>>>       instanceVariableNames: ''
>>>       classVariableNames: ''
>>>       poolDictionaries: ''
>>>       category: 'TMP'
>>> "--"
>>>
>>> with
>>> Foobar>>pvtTest
>>>
>>>       Transcript show: 'Foobar'.
>>>
>>> and then do
>>>
>>> | a |
>>> a := Foobar new.
>>> a pvtTest.
>>>
>>> you'll end up with the Compiler telling you
>>> that “Private messages may only be sent to self”.
>>>
>>> However, according to Smalltalk conventions, you should
>>> use these “private” methods scarcely. In fact, it is easy to
>>> circumvent this check:
>>>
>>> | a |
>>> a := Foobar new.
>>> a  perform: #pvtTest a Foobar
>>>
>>> works easily, so don't rely on the privateness. However,
>>> whatever one sends to your object is up to her/him and
>>> she/he is responsible for the outcome ;)
>>>
>>> HTH
>>>
>>> So Long,
>>>       -Tobias
>>> _______________________________________________
>>> Pharo-users mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

--
 Simon




_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Private methods

YossiDM
This post has NOT been accepted by the mailing list yet.
In reply to this post by Jeff Gray
I come from a C/ASM background, but in my day-to-day work for now I do mainly Java and C#, and work on Smalltalk on weekends/at night until I can do it full-time.

I can empathize with what you are saying, but as the previous posters have alluded, it's not really needed. It's pseudo-protection anyway. Consider in Java and C# you can break private encapsulation with reflection, which is extremely prevalent now as machine performance has increased.  Also consider that most private variables and methods end up just being wrapped with a public wrapper.

You are better off just enforcing it as a convention, with lint rules, or immutable objects depending on what you are doing. If you must have private in Smalltalk, there are a number of previous implementations that probably should still work. I can't think of where off the top of my head, but I think I saw several in the Smalltalk Report journal that used to be around. There are free PDFs of it floating on the web, so give it a google perhaps.
Reply | Threaded
Open this post in threaded view
|

Re: Private methods

Mariano Martinez Peck
In reply to this post by Simon Denier-3
At some point, I don't know now, you could create methods like #pvtMethod  (notice the pvt prefix), and then there was a hack somewhere (maybe in Compiler) where you only could send those methods from self.

I don't know the status of that. Something similar was in VAST (if I remember correclty) where you could put methods in a  'private' category and then someone trows and error if the message was sent from outside self....

cheers

mariano

On Wed, Nov 3, 2010 at 10:42 AM, Simon Denier <[hidden email]> wrote:

On 3 nov. 2010, at 05:47, Igor Stasenko wrote:

> Coding in smalltalk for last 4 years, i seen no problems with having
> no run-time, no compile-time , but instead a coder-time private methods check.
>
> As to me, the benefits of having such constraints in language are exaggerated.


Indeed, for such rules, I think Lint should be the platform of choice (using the parse tree search if necessary).


>
> On 3 November 2010 01:34, Stéphane Ducasse <[hidden email]> wrote:
>> I removed that in pharo since it was a hack working only on squeak and not even well because what happens if
>> I do an alias to self
>>
>>        obj := self.
>>
>>        obj pvt....
>>
>> or with passing a ref to me around and client invoke the method.
>>
>> aA foo: self
>>
>> A>>foo: aA
>>
>>        aA pvt
>>
>> For people that want to read a nice paper on private methods I suggest:
>>        Encapsulation in a dynamic language by nathanael scharly
>>                => only self send (using self keywords could be potential private call) I like the idea and the reasoning behind.
>>
>>        and freezable traits to a certain extent
>>
>>
>> Stef
>>
>>>
>>> Hi
>>>
>>> Am 2010-11-02 um 10:24 schrieb eMko:
>>>> There is a convention of naming private methods - instead of naming it just
>>>> "methodName" you can use "myMethodName".
>>>>
>>>> I have seen this convention in some tutorials at squeak wiki but have not
>>>> seen a system class in squeak or pharo which uses this. But I do in my
>>>> programs. A different naming convention of private/protected methods is
>>>> quite common in other programming or scripting languages like Perl, Python,
>>>> PHP ...
>>>
>>> Incidentally, if you name your method "pvtMethodName" it is expected that
>>> this message is only sent to self.
>>>
>>> So if you have a class
>>> "--"
>>> Object subclass: #Foobar
>>>       instanceVariableNames: ''
>>>       classVariableNames: ''
>>>       poolDictionaries: ''
>>>       category: 'TMP'
>>> "--"
>>>
>>> with
>>> Foobar>>pvtTest
>>>
>>>       Transcript show: 'Foobar'.
>>>
>>> and then do
>>>
>>> | a |
>>> a := Foobar new.
>>> a pvtTest.
>>>
>>> you'll end up with the Compiler telling you
>>> that “Private messages may only be sent to self”.
>>>
>>> However, according to Smalltalk conventions, you should
>>> use these “private” methods scarcely. In fact, it is easy to
>>> circumvent this check:
>>>
>>> | a |
>>> a := Foobar new.
>>> a  perform: #pvtTest a Foobar
>>>
>>> works easily, so don't rely on the privateness. However,
>>> whatever one sends to your object is up to her/him and
>>> she/he is responsible for the outcome ;)
>>>
>>> HTH
>>>
>>> So Long,
>>>       -Tobias
>>> _______________________________________________
>>> Pharo-users mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
--
 Simon




_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Private methods

Stéphane Ducasse
In reply to this post by Simon Denier-3
gone with the wind.
end of discussion.

On Nov 19, 2010, at 7:42 PM, Mariano Martinez Peck wrote:

> At some point, I don't know now, you could create methods like #pvtMethod  (notice the pvt prefix), and then there was a hack somewhere (maybe in Compiler) where you only could send those methods from self.
>
> I don't know the status of that. Something similar was in VAST (if I remember correclty) where you could put methods in a  'private' category and then someone trows and error if the message was sent from outside self....
>
> cheers
>
> mariano
>
> On Wed, Nov 3, 2010 at 10:42 AM, Simon Denier <[hidden email]> wrote:
>
> On 3 nov. 2010, at 05:47, Igor Stasenko wrote:
>
> > Coding in smalltalk for last 4 years, i seen no problems with having
> > no run-time, no compile-time , but instead a coder-time private methods check.
> >
> > As to me, the benefits of having such constraints in language are exaggerated.
>
>
> Indeed, for such rules, I think Lint should be the platform of choice (using the parse tree search if necessary).
>
>
> >
> > On 3 November 2010 01:34, Stéphane Ducasse <[hidden email]> wrote:
> >> I removed that in pharo since it was a hack working only on squeak and not even well because what happens if
> >> I do an alias to self
> >>
> >>        obj := self.
> >>
> >>        obj pvt....
> >>
> >> or with passing a ref to me around and client invoke the method.
> >>
> >> aA foo: self
> >>
> >> A>>foo: aA
> >>
> >>        aA pvt
> >>
> >> For people that want to read a nice paper on private methods I suggest:
> >>        Encapsulation in a dynamic language by nathanael scharly
> >>                => only self send (using self keywords could be potential private call) I like the idea and the reasoning behind.
> >>
> >>        and freezable traits to a certain extent
> >>
> >>
> >> Stef
> >>
> >>>
> >>> Hi
> >>>
> >>> Am 2010-11-02 um 10:24 schrieb eMko:
> >>>> There is a convention of naming private methods - instead of naming it just
> >>>> "methodName" you can use "myMethodName".
> >>>>
> >>>> I have seen this convention in some tutorials at squeak wiki but have not
> >>>> seen a system class in squeak or pharo which uses this. But I do in my
> >>>> programs. A different naming convention of private/protected methods is
> >>>> quite common in other programming or scripting languages like Perl, Python,
> >>>> PHP ...
> >>>
> >>> Incidentally, if you name your method "pvtMethodName" it is expected that
> >>> this message is only sent to self.
> >>>
> >>> So if you have a class
> >>> "--"
> >>> Object subclass: #Foobar
> >>>       instanceVariableNames: ''
> >>>       classVariableNames: ''
> >>>       poolDictionaries: ''
> >>>       category: 'TMP'
> >>> "--"
> >>>
> >>> with
> >>> Foobar>>pvtTest
> >>>
> >>>       Transcript show: 'Foobar'.
> >>>
> >>> and then do
> >>>
> >>> | a |
> >>> a := Foobar new.
> >>> a pvtTest.
> >>>
> >>> you'll end up with the Compiler telling you
> >>> that “Private messages may only be sent to self”.
> >>>
> >>> However, according to Smalltalk conventions, you should
> >>> use these “private” methods scarcely. In fact, it is easy to
> >>> circumvent this check:
> >>>
> >>> | a |
> >>> a := Foobar new.
> >>> a  perform: #pvtTest a Foobar
> >>>
> >>> works easily, so don't rely on the privateness. However,
> >>> whatever one sends to your object is up to her/him and
> >>> she/he is responsible for the outcome ;)
> >>>
> >>> HTH
> >>>
> >>> So Long,
> >>>       -Tobias
> >>> _______________________________________________
> >>> Pharo-users mailing list
> >>> [hidden email]
> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
> >>
> >>
> >> _______________________________________________
> >> Pharo-users mailing list
> >> [hidden email]
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
> >>
> >
> >
> >
> > --
> > Best regards,
> > Igor Stasenko AKA sig.
> >
> > _______________________________________________
> > Pharo-users mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
> --
>  Simon
>
>
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users