Evilness object oriented approach in Morph
Locked
Evilness object oriented approach in Morph
 
|
I have realized that many of the Morph method does not use instance
variable accessor but direct access to the instance variable. One may think this improve the efficiency of the method but in the other hand its downgrade (or just break) the oriented object efficiency of thus objets. Is refactoring the code of the Moprh methods something to be considered? Hilaire |
Re: Evilness object oriented approach in Morph
|
|
Hilaire Fernandes wrote:
> I have realized that many of the Morph method does not use instance > variable accessor but direct access to the instance variable. > One may think this improve the efficiency of the method but in the other > hand its downgrade (or just break) the oriented object efficiency of > thus objets. I hear this argument over and over again, but I tend to disagree about its "evilness". After all, OO is all about *encapsulation* therefore you shouldn't really care about whether a class accesses its *own* iVars via messages or directly. It is only when subclassing comes into play that this causes problems, and perhaps, just perhaps, subclassing is at the root of that evilness? After all it's the subclasses that try to "extend" (some might say "violate") the well-defined behavior of its superclass. Just something to consider. Cheers, - Andreas |
Re: Evilness object oriented approach in Morph
|
|
Andreas Raab a écrit : > Hilaire Fernandes wrote: > >> I have realized that many of the Morph method does not use instance >> variable accessor but direct access to the instance variable. >> One may think this improve the efficiency of the method but in the other >> hand its downgrade (or just break) the oriented object efficiency of >> thus objets. > > > I hear this argument over and over again, but I tend to disagree about > its "evilness". After all, OO is all about *encapsulation* therefore you > shouldn't really care about whether a class accesses its *own* iVars via > messages or directly. It is only when subclassing comes into play that > this causes problems, and perhaps, just perhaps, subclassing is at the > root of that evilness? After all it's the subclasses that try to > "extend" (some might say "violate") the well-defined behavior of its > superclass. Yes, you are right this cause trouble only when I need to extend some of the behavior of some attributes. For example, I need a polygon border to behvave a bit differently depending on the context of the application. But as usual there are workaround and different way to do one think. Hilaire > > Just something to consider. > > Cheers, > - Andreas > > > |
Re: Evilness object oriented approach in Morph
|
|
Hilaire Fernandes wrote:
>>I hear this argument over and over again, but I tend to disagree about >>its "evilness". After all, OO is all about *encapsulation* therefore you >>shouldn't really care about whether a class accesses its *own* iVars via >>messages or directly. It is only when subclassing comes into play that >>this causes problems, and perhaps, just perhaps, subclassing is at the >>root of that evilness? After all it's the subclasses that try to >>"extend" (some might say "violate") the well-defined behavior of its >>superclass. > > > Yes, you are right this cause trouble only when I need to extend some of > the behavior of some attributes. For example, I need a polygon border to > behvave a bit differently depending on the context of the application. > But as usual there are workaround and different way to do one think. I actually disagree. Encapsulation to me also means that you shouldn't know if a value is in an iVar or computed. Refactoring to change the use from an iVar to something computed or delegated is a hell of a lot easier when using message sends. And the almost done jitter will inline the return inst vars anyway, won't it? ;-) Michael |
RE: Evilness object oriented approach in Morph
|
|
> -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Michael Rueger > Sent: Monday, January 23, 2006 2:52 AM > To: The general-purpose Squeak developers list > Subject: Re: Evilness object oriented approach in Morph > > Hilaire Fernandes wrote: > > >>I hear this argument over and over again, but I tend to disagree about > >>its "evilness". After all, OO is all about *encapsulation* therefore you > >>shouldn't really care about whether a class accesses its *own* iVars via > >>messages or directly. It is only when subclassing comes into play that > >>this causes problems, and perhaps, just perhaps, subclassing is at the > >>root of that evilness? After all it's the subclasses that try to > >>"extend" (some might say "violate") the well-defined behavior of its > >>superclass. > > > > > > Yes, you are right this cause trouble only when I need to extend some of > > the behavior of some attributes. For example, I need a polygon border to > > behvave a bit differently depending on the context of the application. > > But as usual there are workaround and different way to do one think. > > I actually disagree. Encapsulation to me also means that you shouldn't > know if a value is in an iVar or computed. Refactoring to change the use > from an iVar to something computed or delegated is a hell of a lot > easier when using message sends. And the almost done jitter will inline > the return inst vars anyway, won't it? ;-) I disagree. :-) In the abstract sense one should not care if you are accessing a state variable or a computed value. However, when you are maintaining or reading code you have to know what is going on. In my experience accessors slows down reading because you cannot assume every message send that looks like an accessor is an accessor. This is not too much of a problem for a class that has only a couple of ivars but is a pain for classes that have several and some that are similar. When you are reading a method and it uses direct ivar reference you know without going further what it is doing. If it is difficult to refactor from an ivar to a message send then the tools need to be fixed. The same logic goes for using accessors because it simpifies debugging. Make the tools serve you instead of the reverse. > Michael |
Re: Evilness object oriented approach in Morph
|
|
In reply to this post by Hilaire Fernandes-5
There is nothing wrong with direct-variable access.
When I first started Smalltalk I thought dogmatic accessors for every single instance variable was a good thing, now I have learned how much clutter and violation of encapsulation it causes. Of course, it seems to be pretty much they do on most Java projects.. For Morphic in particular, look how many methods we have in the API and rendered in the browsers. Less is more. Direct-variable access is an upgrade, not a downgrade. - Chris > Message: 15 > Date: Sun, 22 Jan 2006 12:21:33 +0100 > From: Hilaire Fernandes <[hidden email]> > Subject: Evilness object oriented approach in Morph > To: Squeak Devel > <[hidden email]> > Message-ID: <[hidden email]> > Content-Type: text/plain; charset=ISO-8859-1 > > I have realized that many of the Morph method does > not use instance > variable accessor but direct access to the instance > variable. > One may think this improve the efficiency of the > method but in the other > hand its downgrade (or just break) the oriented > object efficiency of > thus objets. > Is refactoring the code of the Moprh methods > something to be considered? > > Hilaire |
|
|
I prefer emacs, FreeBSD, curly braces at the end of the line,
camelCase, etc, etc... On 1/23/06, Chris Muller <[hidden email]> wrote: > There is nothing wrong with direct-variable access. > When I first started Smalltalk I thought dogmatic > accessors for every single instance variable was a > good thing, now I have learned how much clutter and > violation of encapsulation it causes. Of course, it > seems to be pretty much they do on most Java > projects.. > > For Morphic in particular, look how many methods we > have in the API and rendered in the browsers. Less is > more. Direct-variable access is an upgrade, not a > downgrade. > > - Chris > > > Message: 15 > > Date: Sun, 22 Jan 2006 12:21:33 +0100 > > From: Hilaire Fernandes <[hidden email]> > > Subject: Evilness object oriented approach in Morph > > To: Squeak Devel > > <[hidden email]> > > Message-ID: <[hidden email]> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > I have realized that many of the Morph method does > > not use instance > > variable accessor but direct access to the instance > > variable. > > One may think this improve the efficiency of the > > method but in the other > > hand its downgrade (or just break) the oriented > > object efficiency of > > thus objets. > > Is refactoring the code of the Moprh methods > > something to be considered? > > > > Hilaire > > > |
Re: Evilness object oriented approach in Morph
|
|
In reply to this post by Michael Rueger-6
Michael Rueger wrote:
> Hilaire Fernandes wrote: >>> I hear this argument over and over again, but I tend to disagree about >>> its "evilness". After all, OO is all about *encapsulation* therefore you >>> shouldn't really care about whether a class accesses its *own* iVars via >>> messages or directly. It is only when subclassing comes into play that >>> this causes problems, and perhaps, just perhaps, subclassing is at the >>> root of that evilness? After all it's the subclasses that try to >>> "extend" (some might say "violate") the well-defined behavior of its >>> superclass. >> >> Yes, you are right this cause trouble only when I need to extend some of >> the behavior of some attributes. For example, I need a polygon border to >> behvave a bit differently depending on the context of the application. >> But as usual there are workaround and different way to do one think. > > I actually disagree. Encapsulation to me also means that you shouldn't > know if a value is in an iVar or computed. Refactoring to change the use > from an iVar to something computed or delegated is a hell of a lot > easier when using message sends. And the almost done jitter will inline > the return inst vars anyway, won't it? ;-) Actually, I don't buy the "you shouldn't know" argument one bit :-) Must be because I've been dealing with security stuff too much lately. In security the answer is "no, you shouldn't know - you MUST know" precisely what is an iVar and how it is exposed where. So clearly "you shouldn't know" is not a universal principle but rather comes from a certain design point of view - namely what I would call "design for extensibility" in which one tries to make the classes so that it is easy to reuse and extend them. Which is a very worthwhile goal, but even from this point of view it's not really "you shouldn't know" - it's really "you should use accessors so that it's easy to extend by subclasses" and that therefore, again, in your own code you really *should* know that you are using accessors for the sake of later extensibility. Cheers, - Andreas |
Re: Evilness object oriented approach in Morph
|
|
In reply to this post by Chris Muller-2
Me too. And having a good refactoring tools can support the
introduction of accessors. > There is nothing wrong with direct-variable access. > When I first started Smalltalk I thought dogmatic > accessors for every single instance variable was a > good thing, now I have learned how much clutter and > violation of encapsulation it causes. Of course, it > seems to be pretty much they do on most Java > projects.. > > For Morphic in particular, look how many methods we > have in the API and rendered in the browsers. Less is > more. Direct-variable access is an upgrade, not a > downgrade. > > - Chris |
|
|
In reply to this post by Andreas.Raab
Andreas Raab wrote:
> Michael Rueger wrote: > >> Hilaire Fernandes wrote: >> >>>> I hear this argument over and over again, but I tend to disagree about >>>> its "evilness". After all, OO is all about *encapsulation* >>>> therefore you >>>> shouldn't really care about whether a class accesses its *own* >>>> iVars via >>>> messages or directly. It is only when subclassing comes into play that >>>> this causes problems, and perhaps, just perhaps, subclassing is at the >>>> root of that evilness? After all it's the subclasses that try to >>>> "extend" (some might say "violate") the well-defined behavior of its >>>> superclass. >>> >>> >>> Yes, you are right this cause trouble only when I need to extend >>> some of >>> the behavior of some attributes. For example, I need a polygon >>> border to >>> behvave a bit differently depending on the context of the application. >>> But as usual there are workaround and different way to do one think. >> >> >> I actually disagree. Encapsulation to me also means that you >> shouldn't know if a value is in an iVar or computed. Refactoring to >> change the use from an iVar to something computed or delegated is a >> hell of a lot easier when using message sends. And the almost done >> jitter will inline the return inst vars anyway, won't it? ;-) > > > Actually, I don't buy the "you shouldn't know" argument one bit :-) > Must be because I've been dealing with security stuff too much lately. > In security the answer is "no, you shouldn't know - you MUST know" > precisely what is an iVar and how it is exposed where. So clearly "you > shouldn't know" is not a universal principle but rather comes from a > certain design point of view - namely what I would call "design for > extensibility" in which one tries to make the classes so that it is > easy to reuse and extend them. Which is a very worthwhile goal, but > even from this point of view it's not really "you shouldn't know" - > it's really "you should use accessors so that it's easy to extend by > subclasses" and that therefore, again, in your own code you really > *should* know that you are using accessors for the sake of later > extensibility. > > Cheers, > - Andreas Uh? I thought he meant "you shouldn't know" from *outside* the encapsulation. Obviously from inside you should know what is what. I think you two actually agree. David |
Re: Evilness object oriented approach in Morph
|
|
In reply to this post by Hilaire Fernandes-5
Hi Hilaire,
Yes, refactoring Morphic code is something to be considered. But I'm not a believer of the so called "double encapsulation". If a class has an accessor methods, it allows anyone to know (and enven change!) the value of the instance variable. That is against encapsulation. It is the object (via its class) who defines what it makes public and what it keeps private. If a subclass needs to change that, it's a good time for refactoring. Cheers, Juan Vuletich ----- Original Message ----- From: "Hilaire Fernandes" <[hidden email]> To: "Squeak Devel" <[hidden email]> Sent: Sunday, January 22, 2006 8:21 AM Subject: Evilness object oriented approach in Morph >I have realized that many of the Morph method does not use instance > variable accessor but direct access to the instance variable. > One may think this improve the efficiency of the method but in the other > hand its downgrade (or just break) the oriented object efficiency of > thus objets. > Is refactoring the code of the Moprh methods something to be considered? > > Hilaire > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date: 1/19/2006 > > |
Re: Evilness object oriented approach in Morph
|
|
Not true. If a class has *public* accessor methods, it allows anyone to
know (and even change!) the value of the instance variable. That private methods are enforced by convention rather than by the compiler in Smalltalk shouldn't really change anything. If you want to provide yourself with accessors and you don't want anyone else to use them, put them in a private-something category. "someone else can change my variables" is not really a valid reason to avoid an otherwise-desirable accessor, in my opinion. Next you could say, "I need to write all my code in one long method; otherwise someone could call one of the finer-grained private helper methods directly and get unexpected behaviour". Document your interface with proper categories and then expect people to obey it. If someone decides to use them anyway, screw 'em. Note I'm not getting into the argument of whether you should or should not use accessors to access your own instance variables (not that I don't have some opinions, but I'm not getting into it :) ). Just my 2 cents, Julian Juan Vuletich wrote: > But I'm not a believer of the so called "double encapsulation". If a > class has an accessor methods, it allows anyone to know (and enven > change!) the value of the instance variable. That is against > encapsulation. It is the object (via its class) who defines what it > makes public and what it keeps private. If a subclass needs to change > that, it's a good time for refactoring. > Cheers, > Juan Vuletich |
Re: Evilness object oriented approach in Morph
|
|
In reply to this post by Juan Vuletich
Look like we have two antagonist paradigms: one for reusability (which
is at the heart of OOP) and the other one to protect access to attributes (which is also at the heart of OOP). Given the nature of Smalltalk, code reusability, I like to think the 1st paradigm is more important. But beside that, there are no "rational" excuse to not use accessors instead of direct attribute access; otherwise why defining the accessors? For decoration? Hilaire Juan Vuletich a écrit : > Hi Hilaire, > Yes, refactoring Morphic code is something to be considered. > But I'm not a believer of the so called "double encapsulation". If a > class has an accessor methods, it allows anyone to know (and enven > change!) the value of the instance variable. That is against > encapsulation. It is the object (via its class) who defines what it > makes public and what it keeps private. If a subclass needs to change > that, it's a good time for refactoring. > Cheers, > Juan Vuletich > ----- Original Message ----- From: "Hilaire Fernandes" > <[hidden email]> > To: "Squeak Devel" <[hidden email]> > Sent: Sunday, January 22, 2006 8:21 AM > Subject: Evilness object oriented approach in Morph > > >> I have realized that many of the Morph method does not use instance >> variable accessor but direct access to the instance variable. >> One may think this improve the efficiency of the method but in the other >> hand its downgrade (or just break) the oriented object efficiency of >> thus objets. >> Is refactoring the code of the Moprh methods something to be considered? >> >> Hilaire >> >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date: >> 1/19/2006 >> >> > > -- ADD R0,R1,R2,LSL #2 |
RE: Evilness object oriented approach in Morph
|
|
Actually, there is a reason not to use self accessors, readability.
A method that uses direct variable access is more readable than one that uses an accessor. If it uses an accessor you have to also read that method because it may look like an accessor but may really do more. I have been bitten by this. > -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Hilaire Fernandes > Sent: Wednesday, January 25, 2006 2:45 AM > To: The general-purpose Squeak developers list > Subject: Re: Evilness object oriented approach in Morph > > Look like we have two antagonist paradigms: one for reusability (which > is at the heart of OOP) and the other one to protect access to > attributes (which is also at the heart of OOP). > > Given the nature of Smalltalk, code reusability, I like to think the 1st > paradigm is more important. > > But beside that, there are no "rational" excuse to not use accessors > instead of direct attribute access; otherwise why defining the > accessors? For decoration? > > Hilaire > > > Juan Vuletich a écrit : > > Hi Hilaire, > > Yes, refactoring Morphic code is something to be considered. > > But I'm not a believer of the so called "double encapsulation". If a > > class has an accessor methods, it allows anyone to know (and enven > > change!) the value of the instance variable. That is against > > encapsulation. It is the object (via its class) who defines what it > > makes public and what it keeps private. If a subclass needs to change > > that, it's a good time for refactoring. > > Cheers, > > Juan Vuletich > > ----- Original Message ----- From: "Hilaire Fernandes" > > <[hidden email]> > > To: "Squeak Devel" <[hidden email]> > > Sent: Sunday, January 22, 2006 8:21 AM > > Subject: Evilness object oriented approach in Morph > > > > > >> I have realized that many of the Morph method does not use instance > >> variable accessor but direct access to the instance variable. > >> One may think this improve the efficiency of the method but in the > other > >> hand its downgrade (or just break) the oriented object efficiency of > >> thus objets. > >> Is refactoring the code of the Moprh methods something to be > considered? > >> > >> Hilaire > >> > >> > >> > >> -- > >> No virus found in this incoming message. > >> Checked by AVG Free Edition. > >> Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date: > >> 1/19/2006 > >> > >> > > > > > > > -- > ADD R0,R1,R2,LSL #2 |
Re: Evilness object oriented approach in Morph
|
|
In reply to this post by Hilaire Fernandes-5
I don't like general recipes on how to design and code. If something "must
always be done this way" then it's redundant. It would be better to find a way for not needing to write it. If some time after you wrote a class (or a hierarchy), you need to change the use of an instance variable to something else, you are actually redesigning it. At that moment, you understand why accessing that ivar directly was a bad idea, and you understand your new needs. Therefore, that's a good time to think about the meaning of that value, and find a better solution. Using accessors from the begining, "just in case", means losing the oportunity to think about what you really need, and express that cleanly in the code. I don't think you need an excuse for not using accessors. I think you need a reason to actually use them. Most instance variables do not need accessors and they shouldn't exist. BTW, if a class (or hierachy) needs to "hide" something from itself, maybe it'ss a sign that it's getting too big, and it could be broken in components. Anyway, coding in Smalltalk is a lot about aesthetics and not that much about rational arguments. So it's ok to have different taste. Cheers, Juan ----- Original Message ----- From: "Hilaire Fernandes" <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> Sent: Wednesday, January 25, 2006 4:44 AM Subject: Re: Evilness object oriented approach in Morph > Look like we have two antagonist paradigms: one for reusability (which is > at the heart of OOP) and the other one to protect access to attributes > (which is also at the heart of OOP). > > Given the nature of Smalltalk, code reusability, I like to think the 1st > paradigm is more important. > > But beside that, there are no "rational" excuse to not use accessors > instead of direct attribute access; otherwise why defining the accessors? > For decoration? > > Hilaire > > > Juan Vuletich a écrit : >> Hi Hilaire, >> Yes, refactoring Morphic code is something to be considered. >> But I'm not a believer of the so called "double encapsulation". If a >> class has an accessor methods, it allows anyone to know (and enven >> change!) the value of the instance variable. That is against >> encapsulation. It is the object (via its class) who defines what it makes >> public and what it keeps private. If a subclass needs to change that, >> it's a good time for refactoring. >> Cheers, >> Juan Vuletich >> ----- Original Message ----- From: "Hilaire Fernandes" >> <[hidden email]> >> To: "Squeak Devel" <[hidden email]> >> Sent: Sunday, January 22, 2006 8:21 AM >> Subject: Evilness object oriented approach in Morph >> >> >>> I have realized that many of the Morph method does not use instance >>> variable accessor but direct access to the instance variable. >>> One may think this improve the efficiency of the method but in the other >>> hand its downgrade (or just break) the oriented object efficiency of >>> thus objets. >>> Is refactoring the code of the Moprh methods something to be considered? >>> >>> Hilaire >>> >>> >>> >>> -- >>> No virus found in this incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date: >>> 1/19/2006 >>> >>> >> >> > > > -- > ADD R0,R1,R2,LSL #2 > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date: 1/19/2006 > > |
Re: Evilness object oriented approach in Morph
|
|
One thing to note is that accessors are required when using Traits.
On Jan 25, 2006, at 6:30 PM, Juan Vuletich wrote: > I don't like general recipes on how to design and code. If > something "must always be done this way" then it's redundant. It > would be better to find a way for not needing to write it. > > If some time after you wrote a class (or a hierarchy), you need to > change the use of an instance variable to something else, you are > actually redesigning it. At that moment, you understand why > accessing that ivar directly was a bad idea, and you understand > your new needs. Therefore, that's a good time to think about the > meaning of that value, and find a better solution. > > Using accessors from the begining, "just in case", means losing the > oportunity to think about what you really need, and express that > cleanly in the code. > > I don't think you need an excuse for not using accessors. I think > you need a reason to actually use them. Most instance variables do > not need accessors and they shouldn't exist. > > BTW, if a class (or hierachy) needs to "hide" something from > itself, maybe it'ss a sign that it's getting too big, and it could > be broken in components. > > Anyway, coding in Smalltalk is a lot about aesthetics and not that > much about rational arguments. So it's ok to have different taste. > > Cheers, > Juan > ----- Original Message ----- From: "Hilaire Fernandes" > <[hidden email]> > To: "The general-purpose Squeak developers list" <squeak- > [hidden email]> > Sent: Wednesday, January 25, 2006 4:44 AM > Subject: Re: Evilness object oriented approach in Morph > > >> Look like we have two antagonist paradigms: one for reusability >> (which is at the heart of OOP) and the other one to protect access >> to attributes (which is also at the heart of OOP). >> >> Given the nature of Smalltalk, code reusability, I like to think >> the 1st paradigm is more important. >> >> But beside that, there are no "rational" excuse to not use >> accessors instead of direct attribute access; otherwise why >> defining the accessors? For decoration? >> >> Hilaire >> >> >> Juan Vuletich a écrit : >>> Hi Hilaire, >>> Yes, refactoring Morphic code is something to be considered. >>> But I'm not a believer of the so called "double encapsulation". >>> If a class has an accessor methods, it allows anyone to know (and >>> enven change!) the value of the instance variable. That is >>> against encapsulation. It is the object (via its class) who >>> defines what it makes public and what it keeps private. If a >>> subclass needs to change that, it's a good time for refactoring. >>> Cheers, >>> Juan Vuletich >>> ----- Original Message ----- From: "Hilaire Fernandes" >>> <[hidden email]> >>> To: "Squeak Devel" <[hidden email]> >>> Sent: Sunday, January 22, 2006 8:21 AM >>> Subject: Evilness object oriented approach in Morph >>> >>> >>>> I have realized that many of the Morph method does not use instance >>>> variable accessor but direct access to the instance variable. >>>> One may think this improve the efficiency of the method but in >>>> the other >>>> hand its downgrade (or just break) the oriented object >>>> efficiency of >>>> thus objets. >>>> Is refactoring the code of the Moprh methods something to be >>>> considered? >>>> >>>> Hilaire >>>> >>>> >>>> >>>> -- >>>> No virus found in this incoming message. >>>> Checked by AVG Free Edition. >>>> Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date: >>>> 1/19/2006 >>>> >>>> >>> >>> >> >> >> -- >> ADD R0,R1,R2,LSL #2 >> >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date: >> 1/19/2006 >> > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |