From: benjohn@...
Date: 2006-10-03T16:53:24+09:00
Subject: Re: Creating modules

> On 2006.10.02 20:46, benjohn@fysh.org wrote:
>> I wrote before about the modules I'm trying to build on the fly. I'm
>> going to describe it a bit more and see if anyone has a thought about
>> what I should be doing here, because I'm not making much ground.
>> [Using
>> modules was my latest foray in the direction of another approach, but
>> I
>> think I've given up on that avenue]
>
> Yes, I think the problem is that this is way overcomplicated. Earlier
> you were *subclassing* module which rarely makes sense.

:) I had a try at sub classing Class for a while (I'm still not sure if
that actually makes sense, I _think_ it does), but Ruby doesn't seem to
like that:

irb(main):001:0> class ParameterClass < Class
irb(main):002:1> end
TypeError: can't make subclass of Class
        from (irb):1

*snip*

> Does this mean that
>
>    type = SomeParameterType.new
>    parameter_of_type = type.new
>
> --and if so, why? Classes are there for a reason :)

Yes, that's what I mean. There are a large number of parameter types. I
don't want to describe all of them individually as classes; in fact, I'm
unable to describe them all individually because some of the types of
parameter will not be known about until run time.

I know there are a lot of ways of skinning this. I know that I could
build up each parameter individually, and forget about trying to
describe the classes they have in common (even though I don't want to
describe them all individually)...

The current solution has objects representing the different types of
parameter, which is a start. As those objects are conceptually identical
to classes though (in my brain anyway), I'd like them to actually _be_
classes. I feel that doing so would be concordant with Ruby's object
model, and should lead to an elegant solution.

> Or do you mean that each Type contains metadata for parameters
> of its type?

:) Metadata?

The parameters fall in to a large number of different parameter types.
There is common behaviour between each parameter of a given type. Some
of the parameter types I want to define (but very briefly, without
needing to do...:

class yet_another_parameter;
...
end

...and some I may encounter "on the fly". The types themselves fall in
to a small number of seperate parameter type types (yuck).

*snip*

I also need the parameter_types to exist as objects in their own right;
I need to be able to pass them about them in the program, store them in
tables, and look them up.

>> p.s. I think this lends some support to prototype based information
>> models.
>
> Prototyping is based on cloning *objects*, not classes. If you were to
> take this approach, you would simply a parameter object which exhibited
> the correct behaviour for its type. Instantiating new parameter objects
> would happen by #cloning the prototype and changing values as necessary.
> The prototype object could be constructed either by instantiating a
> class or then in the 'true' style by defining singleton methods on a
> plain Object.

*nods* I think that aligns with what I understood of prototype systems.
The reason I lean towards that approach is because, having done away
with classes, you don't need to decide if something is a class or not. I
would imagine that having a single uniform concept would be a lot
easier. You don't need to think through whether something is a lot like
a class, but isn't really a class because...

However, another post in this thread has given me the hope that if I
have another try at this, I'll be able to come up with a good solution
:)

Thanks for the help,
  Cheers,
    Benj