Re: 0x102a70?

[Javier Guerra <javier@...>]

On Sunday 30 January 2005 8:24 pm, PA wrote:
> On Jan 31, 2005, at 02:02, Javier Guerra wrote:
> > you can compare any kind of value for equality:
>
> Ok... here is what I'm trying to do:
>
> local anArray = { 1, 2, 3 }
> local anotherArray = { 1, 2, 3 }
> print( tostring( anArray == anotherArray ) )
>
> This returns false. For my purpose, I would like it to return true as
> equality is defined by two arrays having the same content, not the same
> address.

this is the 'same leaves' problem, there are several interesting solutions.  
it's used in functional programming classes because there's no simple 
solution without coroutines and/or lazy evaluation

> Further more, consider a table with custom objects which may define
> their own notion of equality:
>
> local aKey = LUObject.new()
> local aValue = LUObject.new()
> local aTable = { aKey = aValue }
>
> aTable.aKey
>
> How do I get 'aTable' to invoke 'aKey' equality methods to return the
> proper 'aValue'?

that seems (to me) like a square peg in a round hole.

if you don't try to define everything in that LUObject, you'll usually find 
simple constructs to do most what you want.  that's why good design usually 
doesn't have deep inheritance.

OOP inheritance is about making generalizations by describing 'not complete' 
classes and add functionality in successive generations.

with FP on the other hand, let's you encapsulate behavior and state with 
closures, not objects.  and you add functionality with higher order functions 
(functions that take other functions (or closures) as parameters).

for example, that's why 'iterators' in FP are so powerfull and so much easier 
to define.  in OOP you can have iterators, but usually they're a subproject 
on their own.

in short: you have experience in OOP, and know how to define it with some set 
of low-level primitives.  but Lua isn't a really good low-level language, so 
the full power isn't with the redefinition of a full OOP.  try to rethink 
your project in terms of functions and closures.  there's nothing wrong with 
objects, but when you build a nice library of functions, you'll find you 
don't need deep inheritance.

take a look at the io library.  the 'file object' is just an opaque object 
with a metatable, there's no need for a huge number of classes to get all the 
functionality (i still shudder at C++ streams classes)

-- 
Javier

Attachment: pgpH819bNKtqL.pgp
Description: PGP signature