[#1649] Re: New Ruby projects — Yukihiro Matsumoto <matz@...>
The following message is a courtesy copy of an article
[#1672] Re: Ruby 1.4 stable manual bug? — Yukihiro Matsumoto <matz@...>
The following message is a courtesy copy of an article
[#1673] Re: Possible problem with ext/socket in 1.5.2 — itojun@...
[#1694] Conventions for our Ruby book — Dave Thomas <Dave@...>
[#1715] Install postgresql support — Ikhlasul Amal <amal@...>
Hi all,
Hi,
[#1786] Is this a bug? — Clemens Hintze <clemens.hintze@...>
(mailed & posted)
[#1814] Objects nested sometimes. — Hugh Sasse Staff Elec Eng <hgs@...>
I am attemptiong to write a package which consists of a workspace
[#1816] Ruby 1.5.3 under Tru64 (Alpha)? — Clemens Hintze <clemens.hintze@...>
Hi all,
Hi,
Yukihiro Matsumoto writes:
Hi,
Hi,
[#1834] enum examples? — Hugh Sasse Staff Elec Eng <hgs@...>
Has anyone any examplse of using the Enumerable module? I've had a
[#1844] Minor irritation, can't figure out how to patch it though! — Hugh Sasse Staff Elec Eng <hgs@...>
I was considering how difficult it would be to patch Ruby to accept
[#1889] [ruby-1.5.3] require / SAFE — ts <decoux@...>
[#1896] Ruby Syntax similar to other languages? — "David Douthitt" <DDouthitt@...>
From: Yukihiro Matsumoto <matz@netlab.co.jp>
[#1900] Enumerations and all that. — Hugh Sasse Staff Elec Eng <hgs@...>
Thank you to the people who responded to my questions about Enumerated
Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes:
On 16 Mar 2000, Dave Thomas wrote:
[#1929] Re: Class Variables — "David Douthitt" <DDouthitt@...>
| "David Douthitt" <DDouthitt@cuna.com> writes:
[#1942] no Fixnum#new ? — Quinn Dunkan <quinn@...>
Ok, I can add methods to a built-in class well enough (yes I know about succ,
[#1989] English Ruby/Gtk Tutorial? — schneik@...
Hi,
[#2022] rb_global_entry — ts <decoux@...>
[#2036] Anonymous and Singleton Classes — B_DAVISON <Bob.Davison@...>
I am a Ruby newbie and having some problems getting my mind around certain
[#2069] Ruby/GTK+ question about imlib --> gdk-pixbug — schneik@...
[#2073] Re: eval.rb fails — "Dat Nguyen" <thucdat@...>
The doc is fine, this happens only if you try to execute 'until' block
On Wed, 22 Mar 2000, Dat Nguyen wrote:
[#2084] Scope violated by import via 'require'? — Clemens Hintze <c.hintze@...>
Hi,
[#2104] ARGF or $< — Hugh Sasse Staff Elec Eng <hgs@...>
Has anyone any examples of how to use ARGF or $< as I cannot find much
Hi.
[#2165] Ruby strict mode and stand-alone executables. — "Conrad Schneiker" <schneiker@...>
Some people want Ruby to have a strict compile mode.
[#2203] Re: parse bug in 1.5 — schneik@...
[#2212] Re: Ruby/Glade usage questions. — ts <decoux@...>
>>>>> "m" == mrilu <mrilu@ale.cx> writes:
[#2241] setter() for local variables — ts <decoux@...>
[#2256] Multiple assignment of pattern match results. — schneik@...
[#2267] Re: Ruby and Eiffel — h.fulton@...
[#2309] Question about attribute writers — Dave Thomas <Dave@...>
Clemens Hintze <c.hintze@gmx.net> writes:
[ruby-talk:01820] Re: Objects nested sometimes.
Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes:
> sort of thing? I'm just a bit unsure about the instance
> variables in both types -- I know I can make them public with
> attr() but that creates *functions* to access them[?], so will
> that mean that the port cannot point to the parent's variables,
> or not? I will have several nodes and several ports, so it
> must be the case that the voltages (for a node or a port) are
> not shared across all instances of the same type (node or
> port). Hence my question about instance variables.
Well, I guess I'd probably ask "why do you want to point to your
parent's variables in the first place".
It seems to be me are two scenarios:
1. You need the values of the voltages *at the time* the node is
created. In that case you'd want to copy the parent's values down.
2. You need the *current* values of the parent's voltages. In that
case, why have an extra set of instance variables in the child, as
you can always get to the parent's values when you need to?
However, there is a third point. There's an OO design principle,
somewhat imperiously called The Law of Demeter, which basically says
you shouldn't go groveling around inside sub-objects, because it
increases coupling in your code, making it more difficult to
maintain. In this case, we have a Node, that contains a number of
Ports. The LOD would say that
v = aNode.getPort(1).getVoltage(2)
is bad form, because you're asking a sub-object of Node (a Port) to do
something. The LOD says it would be better to hide the implementation
of Ports within Nodes by doing something like:
v = Anode.getPortVoltage(1, 2)
Now, I'm not particularly trying to push the Law of Demeter here--I
break it every day. However, sometimes, when things start to get all
tangled, it can help point the way towards simplifications. Perhaps
the problems you're having are not with the storage of data, but with
its access?
Now I know absolutely nothing about your problem, so this may be just
a load of bollocks. Please ignore it if so ;-)
Regards
Dave