Re: Class Level inheritable attributes - are we there yet?

Hi,
Before answering to Roberts specific questions, as the OP i'd like to 
show the 'common sense' analogy from an outsiders perspective. This 
analogy is of real-life taxonomy, and real darwinian evolution. Its sort 
of 'how nature would do it'.

So a class is the species of animal.
An instance object is an individual animal that has been born, and is 
living.

The sub-species (subclass) will inherit everything and permutate / 
mutate the ancestor class.
An object instance can inherit all of the same. The difference is that a 
species doesn't individually live many lives, it is 'a model instance'. 
Wheras an object instance is free to lead any kind of a life, and there 
may be many permutations of such.

The species are in evolution are generally minimal. (you only get new 
ones when they are peoperly justified). There can be many objects, but 
comparatively few species.

One species of centipide has 5 body segments and 10 legs
All instances of that species also has 5 body segments and 10 legs
They also have common behaviours (methods) such as running, twisting, 
etc.

A new sub-species (subclass) is formed which has [6 seg, 12 legs]. But 
it still has 5 eyes, 1 mouth, and so on. These are inherited values. The 
new species can't correctly execute its inherited methods {run and 
twist} if its body mechanism (when derived) always ever inherits a 
default number of 0 arms, 0 legs, 0 body segments, and 0 everything 
else.

1) So above is the 'common sense' paradigm. (actually i originally was 
asking around for). So clearly meaning its requiring deep-copy. But 
because we are talking about classes and not object then there should be 
much fewer of declared in your program.

2) To share same attribute amongst classes (with rubys default shallow 
copy) are generally helpful for certain global constant etc in a library 
environment. (myself didn't ask for that but its clearly both variation 
are needed).

3) When in ruby we instantiate an object, we don't always want to copy 
these same attributes above (1 and 2) into the instance. (whether or not 
they are type 1 or 2 doesn't matter). Reason: not want to deep-copy 
excessively because we can have many instance object (which may or may 
not use the class attribute). For example, think of the lazy centipede. 
It wants to {twist and wriggle}, but can't be bothered to run, so it 
doesn't hardly ever use its legs. So if we chopped the legs off, it 
wouldn't matter for the most part.


Robert Klemme wrote:
> 2009/10/13 ara.t.howard <[e-mail]>:
> OK, let's start over.  For that first I would like to understand what
> the problem actually is that needs to be solved here.  There are many
> aspects to this and I would love to see something like a requirements
> list which particularly states the problem.  Questions I have in mind:
> 
> - Do those attributes need to change or are they set once (quasi /
> real constant)?

Yes, they need to be able to change and be any regular ruby object.
As per case 1)

> - If a subclass inherits a value from the superclass is it supposed to
> inherit changes to the value as well?

No for 1), yes for 2)

> - What happens if a super class has its attribute unset?  You might
> want to retain all sub class values - or not.

Thats the same answer as the previous question.

> - What happens if a super class has its attribute set?  You might want
> to override all sub class values at this moment.

Thats also the same answer as per the previous question.
Or i dont understand these questions.

> - Must modules along the inheritance chain get their own values or is
> the feature in question restricted to class instances?  (Note, it's
> almost impossible to include modules here because they may be part of
> multiple inheritance chains.)

We don't want any polymorphic behaviour because it doesn't fit right 
with natural evolution. In nature you can't cross a horse species with a 
duck species to have a flying horse eh?

> - Is the feature expected to work with different combinations to the
> questions above.

Yes.
Its important to cover the fewest number of cases, and ensure a clear 
differentiation between them. Im not 100% sure that fattr.rb syntax is 
the best / most readable.


And also before we implement a solution, i hope also we can work out a 
good clear syntax and do good example usages beforehand. Find the best 
(to the end user) presentation so to show clearly and differentiate 
between them. Otherwise it could be very unfriendly / confusing.

Options
* Whether it be a special character(like@), a special symbol (:sym),
* Wrapped in class << self (or not)
* Some accessor definition with argument
* Or some opt-in list, where must reference / redeclare attribute a 
second time.
* any other diy DSL syntax, as long as it has merit



Best regards,

dreamcat4
[e-mail]
-- 
Posted via http://www.ruby-forum.com/.