Re: Holub on getters/setters again

From: Daniel T. (postmaster_at_eathlink.net)
Date: 01/25/04 

Date: Sun, 25 Jan 2004 22:50:44 GMT

Ron Jeffries <ronjeffries@REMOVEacm.org> wrote:

> On Sun, 25 Jan 2004 06:14:06 GMT, "Daniel T." <postmaster@eathlink.net>
> wrote:
>
> >> Nonetheless, in this context the ArrayList seems almost equally tacky to
> >> me
> >> whether copied or not. If you agree, what rule of thumb or other digit
> >> would
> >> you
> >> use to call attention to this?
> >
> >I've been wondering the same myself. I've started to post a thought
> >several times, but stopped because the thought isn't complete yet... But
> >here it goes anyway.
> >
> >Once the Contents method is changed into a factory method as I have
> >suggested. It can almost be said that it isn't a getter anymore even by
> >my definition of the word. What it is returning isn't the state of the
> >Set, but another object that happens to have the same state as the set.
> >There may be a problem inherent with that.
>
> Yes, I think so. It isn't "just happens". The intention is that it does have
> the
> same state. There is, as far as I can see, no reason to have the ArrayList at
> all. It should, in principle, offer no functionality that the Set could not.
> >
> >Part of the problem, it seems to me, is that the Set class was written
> >before the client that uses it was written. If you had written the
> >client code first, you would have naturally called foreach on the Set
> >itself. When the servers implementation is running the show, things get
> >messed up. In this case, the server's implementation decided the servers
> >interface, which forced the client code to be written a certain way.
> >This is backwards from how it should be. It should be the client
> >implementation determining the server interface...
>
> This is an interesting fantasy but it is counter to fact. I wrote the Set
> when I
> needed it. And I knew I wanted to call foreach on it from the very beginning,
> both because of the current client and because I know what collections are
> supposed to do.
>
> The reason that I didn't implement foreach was that it is slightly tricky,
> I've
> only done it once in C#, and I was on a mission to get something done. So the
> hack of returning the ArrayList let me return to the real purpose.
>
> It's true that implementing Set first in a clueless fashion might have led to
> the same result. But when you consider that they are all my code, in my
> program,
> and if you grant me the possibility of having a clue about what's good and
> what's bad, it's necessary to look for another reason. In this case the
> reason
> is simple, and fairly common in real life: I can get done faster if I do this
> in
> a less than optimal way.
>
> If I add the Set to my general library of objects, this reasoning will
> remain
> oddly true ... every time I need to loop over a set, it will be easier to
> just
> call Contents and loop over it. But every time I do this, there will be an
> extra
> method call in the code. Over time, it will add up to worse and worse code
> all
> over the universe, until finally we are all bogged down in calls to Contents.
>
> I hope that I have the energy to do it right before that happens. ;->

I guess thats the problem with doing the simplest thing that works... It
occurs to me that if this was C++ one could simply write a stand-alone
function that conditionally adds elements to a container depending on
whether the element already exists in that container. Then just use the
ArrayList like normal, but keeping in mind that one must go through some
special function to add things to it. Or we could make our Set class a
decorator that can be used with any other sort of container... Or one
could derive from ArrayList and simply override the methods that add
elements (if c# allows sub-classing from ArrayList...)

So many options...

Relevant Pages

  • Re: Holub on getters/setters again
    ... >before the client that uses it was written. ... When the servers implementation is running the show, ... And I knew I wanted to call foreach on it from the very beginning, ... The reason that I didn't implement foreach was that it is slightly tricky, ...
    (comp.object)
  • Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
    ... server model on its head and constructing as much of the widgets ... client-side, and your framework at ... may dump the majority of the processing off to the client and the server acts ... between displaying a container or hiding a container ...
    (comp.lang.lisp)
  • Re: Exposing contained types.. Especially LISTS
    ... For the client that ... Test Product pretty much looks like a container with the added ability ... But what if you have lots of Bottom ... lists floating out there, and each could carry the name of its book... ...
    (comp.object)
  • Re: Silly question of the day #2: Hosted e-mail vs. Exchange on SBS2003
    ... My second reason depends on the hosting company. ... When I last had hosted e-mail, the hosting company had an aggressive and undocumented spam control plan that caused me a lot of problems. ... why would it be a better idea to leave the e-mail with the current hosting company vs. moving to Exchange 2003 SP2 when we are moving a client to SBS2003? ... They are using various Clients (he does not know what they use...he *thinks* they use the web mail "client" provided by the Hosting Company) to access e-mail remotely. ...
    (microsoft.public.windows.server.sbs)
  • Re: Killing threads
    ... >>>the proces of serving a client for any reason, ... The server thread actually forks new ... > recover a thread that is taking too long for whatever reason. ...
    (comp.programming.threads)