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 <[email protected]> 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 <[email protected]> > 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 > >>> [email protected] > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> > >> > >> _______________________________________________ > >> Pharo-users mailing list > >> [email protected] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > _______________________________________________ > > Pharo-users mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > -- > Simon > > > > > _______________________________________________ > Pharo-users mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >
_______________________________________________ Pharo-users mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
