Private methods
Locked
 
|
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 :-) |
|
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 |
|
|
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 ... |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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. |
|
|
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:
_______________________________________________ Pharo-users mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users |
|
|
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 |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |