Re: The Third Ruby - Ever Comes Out at Night?

On 02.10.2010 17:42, Mike Stephens wrote:
> It's beginning to firm up up in my mind.
>
> OO treats data and methods as intertwined. An object has its data and
> its methods.

More importantly: they are connected!  Methods work on an instance's 
state, read and update it.  By encapsulating state you gain added 
robustness because by maintaining a class invariant your objects are 
always in a valid state.  Anybody (including procedures) can change 
elements of a structure in arbitrary ways, which is much less robust.

> Procedural treats methods and data as two groups on each
> side of the dance floor, changing partners as the night proceeds.

But you cannot apply a procedure on arbitrary data.  Input and output 
types need to fit the data at hand.

> With procedural you can carry out data analysis and create a database
> based on the qualities of the data rather than any consideration of what
> methods are going to use them and in what way.

Hm...  I don't think people write database schemas without any thought 
to the intended usage.  And that intended usage also manifests in the 
constraints which are placed in the schema.  Illegal usage is 
prohibited.  It goes into the same direction as what OO does (see above) 
only that it is not as strict.

> Similarly you can create a structure of procedures that describe how you
> are going to address the task of the program, without at that point
> considering data in any detail.

How exactly do you do that?  I mean, you can write down names of 
procedures and which calls which but you need specific types once you 
implement them - and likely earlier (i.e. when you do the design).

> Eventually the procedures map onto the data structure but tend to share
> 'objects' with other procedures. I guess often you could group data and
> procedures into 'classes' as they will have patterns of 'closed' usage,
> but you don't have to.
>
> On a separate tack, procedural doesn't hide methods (because it doesn't
> have the language feature to do so) so a procedural program will trust
> other programmers not to abuse code.

That's not true on this level of abstraction of the discussion.  And 
there are indeed procedural languages that allow access control: Modula 
2 and PL/SQL come to mind.  These have a concept of module which allows 
to make certain things (procedures and data) only visible from inside 
the module.  I don't know Ada but I bet it has similar mechanisms.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/