Access modifier missing in ST ??
Locked
 
|
"is it not a limitation of ST that an object allows all of its implemented methods to be accessed by any other objects ?" Can someone tell me if it is intentionally so,if yes what is the advantage of ST being like that???
Mani _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Access modifier missing in ST ??
|
|
On 5/25/13 9:16 AM, mani kartha wrote:
> > a C# developer today asked me > "is it not a limitation of ST that an object allows all of its > implemented methods to be accessed by any other objects ?" > > Can someone tell me if it is intentionally so,if yes what is the > advantage of ST being like that??? Hi Mani, I think it's a feature, rather than a limitation. When you get a Smalltalk product or distro, some of the methods are marked private via a protocol or some kind of annotation or property. That means that the developer or producer of the class thinks that those methods shouldn't be called from outside the class. But you can, if you need to. It means that you need to be careful to look at why the method was private and whether you have to do anything extra to ensure that you don't break anything. It means flexibility. It means that as a Smalltalk developer you can't be condescending to those who use your code. "We think we know how you should use this, but you might have a use case we haven't thought of" instead "WE KNOW EVERY POSSIBLE USE YOU COULD PUT THIS TO AND THIS IS FOR YOUR OWN GOOD". If someone thinks it's a limitation, he's welcome to. I think it's an advantage. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Access modifier missing in ST ??
|
|
In reply to this post by mani kartha
> a C# developer today asked me > "is it not a limitation of ST that an object allows all of its implemented methods to be accessed by any other objects ?" having public methods is the simplest model. Because if you want to have protected methods then you need to be able to distinguish between self sends sent from the class and those that are not from a client. And since in Smalltlak there is no static type annotation you cannot simply identify such cases. There are approaches (we are checking one) based on the different between self x and anObject x. > > Can someone tell me if it is intentionally so,if yes what is the advantage of ST being like that??? > > > Mani > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
C# / Java presumes that there are several capability levels of developers and thereby mandated various constructs as carried over from C++, and some more of its own. Smalltalk mandates all developers in the codebase are equally capable and know what is the right design and abide by it. There are pros and cons to both approaches, but as Smalltalk currently sits it is perfectly sensible, unless it gets to be used in a large project with 100+ fresh Smalltalkers with no comprehension of design/ code practices.
How about public, private, protected variables..? Smalltalk treats all instance vars of a class as private. ( you could do a instVarAt: .. magic though.. ) On Sun, May 26, 2013 at 12:07 AM, stephane ducasse <[hidden email]> wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Tom Robinson-3
On 5/25/2013 2:32 PM, Tom Robinson
wrote:
On 5/25/13 9:16 AM, mani kartha wrote:Well said. Many other languages assume that the programmer is an ignorant maniac just itching to do digital harm and therefore the language must protect against that with constructs like Double Plus Protected Private Static NeverSubclass. Smalltalk assumes that you know what you are doing. Methods marked as private are private for a reason, and you should understand that reason before using them. But you can if you want to. You can even do something like: Object allSubclasses do: [:each | each become: nil] which is the Smalltalk equivalent of running rm -rf * as superuser from the / directory. -- Donald [|] Joel Cairo: You always have a very smooth explanation... Sam Spade: What do you want me to do, learn to stutter? - The Maltese Falcon _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Access modifier missing in ST ??
|
|
In reply to this post by mani kartha
Dear Mani,
>a C# developer today asked me >"is it not a limitation of ST that an object allows all of its implemented >methods to be accessed by any other objects ?" > >Can someone tell me if it is intentionally so,if yes what is the advantage >of ST being like that??? > > It is intentionally so. This is just a particular example of Smalltalk's assumption that the future is likely not to be exactly what a given developer imagines at a given moment. Assigning enforced protected or private state, like assigning types, is an example of assuming you know the correct answers at the start, and must make it difficult for future users of your code to make silly mistakes. Not assigning them is assuming that future programmers may want to do something very sensible or even essential that you did not foresee. Smalltalk is based on the second viewpoint. It aims to minimise the 'tax' that such things impose on refactoring code. The opinion of Smalltalkers is that Smalltalk programs last longer and can be used in more ways because Smalltalk does not tax refactoring. (Obviously, you can have sandboxes and various other kinds of access traps in specific cases, but by making it a piece of work to do anything like that, Smalltalk ensures you will program in an open manner unless you're very very sure some specific case needs other handling.) Yours faithfully Niall Ross _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Access modifier missing in ST ??
|
|
+1 to what everyone said. But sometimes a real-world example is helpful too.On Sun, May 26, 2013 at 10:22 AM, Niall Ross <[hidden email]> wrote: Dear Mani, _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Access modifier missing in ST ??
|
|
+1 Actually, I find 'final' for classes/methods the worst modifier ever.
Am 28.05.2013, 19:18 Uhr, schrieb Jon Paynter <[hidden email]>: > +1 to what everyone said. > > But sometimes a real-world example is helpful too. > Recently I was working on a java project and using a 3rd party library, > and > creating a collection of "things" as a part of my use I needed to update > some of the instance vars of the objects in my collection. however, > the > library developer declared all the instance vars as private, and declared > the class as 'final' ... In the end, I had to destroy the collection > and > and re-create each member with the new values -- horribly inefficient. > > > On Sun, May 26, 2013 at 10:22 AM, Niall Ross <[hidden email]> > wrote: > >> Dear Mani, >> >> >> a C# developer today asked me >> It is intentionally so. >> >> This is just a particular example of Smalltalk's assumption that the >> future is likely not to be exactly what a given developer imagines at a >> given moment. Assigning enforced protected or private state, like >> assigning types, is an example of assuming you know the correct answers >> at >> the start, and must make it difficult for future users of your code to >> make >> silly mistakes. Not assigning them is assuming that future programmers >> may >> want to do something very sensible or even essential that you did not >> foresee. >> >> Smalltalk is based on the second viewpoint. It aims to minimise the >> 'tax' >> that such things impose on refactoring code. The opinion of >> Smalltalkers >> is that Smalltalk programs last longer and can be used in more ways >> because >> Smalltalk does not tax refactoring. >> >> (Obviously, you can have sandboxes and various other kinds of access >> traps >> in specific cases, but by making it a piece of work to do anything like >> that, Smalltalk ensures you will program in an open manner unless you're >> very very sure some specific case needs other handling.) >> >> Yours faithfully >> Niall Ross >> >> >> ______________________________**_________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/**mailman/listinfo/vwnc<http://lists.cs.uiuc.edu/mailman/listinfo/vwnc> >> _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Access modifier missing in ST ??
|
|
On May 28, 2013, at 7:43 PM, Steffen Märcker <[hidden email]> wrote: +1 Actually, I find 'final' for classes/methods the worst modifier ever. :)
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |