POV-Ray : Newsgroups : povray.off-topic : GIMP hotkeys/ scripts/ user-defined functions? : Re: Undirected rambling Server Time
7 Sep 2024 07:22:29 EDT (-0400)
  Re: Undirected rambling  
From: Darren New
Date: 12 Dec 2008 13:20:00
Message: <4942ab50$1@news.povray.org>
Invisible wrote:
> You don't have to pass it explicitly though. It's a simple matter to use 
> a state monad, and then you don't have to care about any state 
> information except in the places where you actually use it.

Don't you have to pass the state monad around?

> And I had this trouble before I went to Uni, over a decade before I 
> learned functional programming.

I'm not saying it's *because* you wrote in a functional style, which is 
clearly close to impossible in Smalltalk. I'm saying it's because you wrote 
in a non-OO or not-very-OO style.

> Yeah, but if you changed a collection to a non-collection, surely you 
> must have intended to change the _behaviour_ of the code, so you'll need 
> to change it anyway.

Yes, but hopefully in only one place. There shouldn't be a lot of places in 
your OO code that know what's in that collection if it's reasonable to 
change the collection to a non-collection.

Obviously, if your image has a collection of pixels, you're not going to be 
able to change that to a non-collection, so the question is moot.

If your server accepts commands from a socket and you change it to accept 
commands from many sockets at once, then the "get next command" is pretty 
much the only method you should have to change. Nobody outside the "command 
reception" class should know how many sockets you have.  If your server is 
issuing socket.read() calls from inside the body of the server that you'd 
need to change, you've structured your code incorrectly.

> Personally, I prefer the reassurance of knowing that the caller is going 
> to pass in the right kind of data. :-P

I do too many things where the data has to change over time to get away with 
that sort of stuff. Sure, I pass in a hash table mapping strings to values, 
but nowhere keeps track of what the keys may be. (Indeed, the one place of 
enforcing that only the right keys got written to the database was the 
primary place I forgot to fix when adding new types of information to the 
system.)

> On the other hand... haven't you ever written code where you reassign 
> responsibilities that used to be in one place, but are now in another 
> place? 

Yes. Less and less as time goes on.

> Haven't you ever tried to modify some object, and then gone "oh, 
> wait, that isn't the Customer object, it's a WeakReference to the 
> Customer object"?

Yes. Less and less as time goes on. :-)  I've learned how painful writing OO 
software like that is, and I now avoid it.

> I didn't say "run" - I say "run *and develop*". C runs in places where 
> JavaScript never will, but how many places have a C compiler? By 
> contrast, almost _everywhere_ has a web browser and some kind of text 
> editor.

I see what you mean.

> (The only real problem are those few places which run Linux but don't 
> have X Windows. I'm reasonably sure there are no text-mode browsers that 
> run JavaScript, and sometimes the only text editor available is Emacs.)

There are non-browser based javascript interpreters, too.

> Depends if you're adding new data. Maybe you added a new object to the 
> chain just so that you can replace part of the structure with a single 
> assignment?

If you're assigning to that from outside the class that's encapsulating 
that, you've done something wrong.

> As you might have noticed, there are immunerable language extensions for 
> Haskell. Usually the "documentation" for these consists of a dozen lines 
> of "self-explanatory" example code...

Yeah. I can't tell you how often people have said "The interface is easy. 
It's XML."   "Oh, can I have the schema?"   "We don't have one, but here's 
some example records."   WTF?

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.