From: Eero Saynatkari <ruby-ml@...>
Date: 2006-10-03T00:23:42+09:00
Subject: Re: Creating modules

--R+Rs1qz93vBJxC1z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.

> What I have are messages and parameters. I'll concentrate on parameters.
>=20
> Parameters - I have instances of a parameter. Each parameter is an
> instance of a type of parameter.
>=20
> There are about 20 known types of parameter. I must also support unknown
> types of parameter (which I will generate on the fly and furnish with
> minimal generic behaviour). The known parameters fall in to two groups:
> those that have a simple encoding and those with more complex encoding.
> To sumarise, the types of parameter have a hierarchy:
>=20
> ParameterType
> UnknownParamerType < ParameterType
> KnownParameterType < ParameterType
> SimpleParameterType < KnownParameterType
> ComplexParameterType < KnownParameterType
>=20
> Remember that instances of these parameter types are not actual
> parameters, they are the classes that parameters instances fall in to.

Does this mean that
=20
   type =3D SomeParameterType.new
   parameter_of_type =3D type.new=20

--and if so, why? Classes are there for a reason :)

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

> At the moment, I have a sepererate class for Parameter. Instances of
> this delegate to a ParameterType instance. This is annoying me though:
> it seems more complex than it ought to be.
>=20
> I've tried quite a few approaches to putting all this together, but
> nothing seems to fit the problem very well.
>=20
> Any thoughts? Sorry if the above isn't very clear!

I think your problem comes from trying to (if I understand correctly)
separate Parameters and ParameterTypes.

I do not pretend to understand the problem domain but I do think you need=
=20
to go back to basics and just implement the system traditional OO. If a
parameter type has behaviour differing from its siblings, define it a
separate class.=20

  class Parameter; end
  class UnknownParameter < Parameter; end
  class KnownParameter < Parameter; end
  class SomeParameterType < KnownParameter; end

  # Aha, got a SomeParameter
  my_param =3D SomeParameter.new arguments, go, here

> Cheers,
>   Benjohn Barnes
>=20
> p.s. I think this lends some support to prototype based information model=
s.

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.

--R+Rs1qz93vBJxC1z
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFFIS6I7Nh7RM4TrhIRAkfeAKC7JC0OKbO7DmNqvkfJV0dwnbbqYQCfSgNP
f+gGYJRv2FKVagPbCExM8BE=
=JyJn
-----END PGP SIGNATURE-----

--R+Rs1qz93vBJxC1z--