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.
This is a classical case I would resolve with instance methods that
return constant values because the information is not needed at class
level but at instance level. So we get
class Centipide
def mouths; 1 end
def eyes; 5; end
def body_segments; 5 end
def legs; 10 end
def run
puts "opening my #{eyes} eyes and starting to move"
legs.times do |i|
puts "moving leg #{i}"
end
end
end
class SubCenti < Centipide
def body_segments; 5 end
def legs; 10 end
end
Strictly speaking the class does not have segments, legs etc. - only
instances have. The scheme with instance methods can be kept even if
you provide for individual (i.e. per object) values by providing a
default via constant methods similar to those shown above.
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.
Btw, deep copy is usually used in the context of copying object
graphs. If I understand you correctly you mean something else
(inheriting values through hierarchies).
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).
Again, shallow copy seems to be a misnomer here.
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:
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?
But you can have duck typing! 
- 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.
My understanding of the above is this. You have two use cases in mind:
1. Inheriting dynamic attribute values defining a proximity rule, i.e.
when asked you get the closest attribute.
2. Constants which with the same proximity lookup rule as above only
that values do not change after the initialization.
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.
Yes, although the syntax could be viewed as part of the solution.
Before promoting something to the standard library I would also like
to know how much use cases there are. In other words if (unlikely
worst case) you and Ara would be the only once that have a need for
this then I'd vote for not including in the std lib.
Right now I have two issues:
1. I still have not seen a use case which would cry for a library
solution which is not there yet (see above). (I still need to ponder
the board example in your other email.)
2. It seems there are not many people wanting this (yet) - which might
well be caused by the fact that I don't read every single posting to
ruby-talk. I do have a feeling though that if there was massive
demand for this we would see it in the std lib by now.
Kind regards
robert
···
2009/10/13 Dreamcat Four <dreamcat4@gmail.com>:
2009/10/13 ara.t.howard <ara.t.howard@gmail.com>:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/