Hi:
I have always had a doubt about OOP.
Usually we have a parent and several child, but what happen if we need
the inverse system. for example DBI/DBD APIs.??
I need build map proyections and i want and intermediate API for all
proyections clases.
All map proyections have the same methods (geodetic_to_projected and
projected_to_geodetic)
Regards.
On 24 Apr 2008, at 10:40, Martin V. wrote:
projected_to_geodetic)
Then define either a projection class from which they all inherit, or
a projection module which they all include.
Ellie
raise ArgumentError unless @reality.responds_to? :reason
On 24.04.2008 12:15, Eleanor McHugh wrote:
On 24 Apr 2008, at 10:40, Martin V. wrote:
I have always had a doubt about OOP.
Usually we have a parent and several child, but what happen if we need
the inverse system. for example DBI/DBD APIs.??I need build map proyections and i want and intermediate API for all
proyections clases.
What exactly do you mean by “intermediate”? Do you mean that all
projections should have the same interface? For that you do not need
inheritance at all - at least in Ruby. Or do you rather mean that they
share behavior (implementation)?
All map proyections have the same methods (geodetic_to_projected and
projected_to_geodetic)Then define either a projection class from which they all inherit, or
a projection module which they all include.
Nice reading from you again, Ellie. 
I was going to also suggest the module approach. But I do wonder why
Martin chose to call it “inverse OOP”. It seems the more appropriate
term would be “multiple inheritance” or am I missing something?
Cheers
robert
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Apr 24, 2008, at 11:40 AM, Martin V. wrote:
Hi:
I have always had a doubt about OOP.
Usually we have a parent and several child, but what happen if we need
the inverse system. for example DBI/DBD APIs.??
Actually, thats quite a common problem of thought, because inheritance
is often considered
as the problem solver in OOP. But that is not the case. I for my
part seldomly inherit.
The core feature of OOP is composition. So even without modules, you
could just implement
a class that has a certain set of features and hands everything else
to a class that has a
concrete implementation for that task (delegation, btw. 
).
Depending on the language, this can get large because of the vast
amount of
boilerplate code you have to write for the delegating methods, but in
Ruby, this is a simple task.
Regards,
Florian G.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkgRHZ8ACgkQJA/zY0IIRZbPZgCgp/Vx54NYWH6PppPXRENXic3s
OwEAn2SFwl0BnIJsu+fvc4+RUBlUGbn/
=tD69
-----END PGP SIGNATURE-----
Robert K. wrote:
On 24.04.2008 12:15, Eleanor McHugh wrote:
On 24 Apr 2008, at 10:40, Martin V. wrote:
I have always had a doubt about OOP.
Usually we have a parent and several child, but what happen if we need
the inverse system. for example DBI/DBD APIs.??I need build map proyections and i want and intermediate API for all
proyections clases.What exactly do you mean by “intermediate”? Do you mean that all
projections should have the same interface? For that you do not need
inheritance at all - at least in Ruby. Or do you rather mean that they
share behavior (implementation)?
Same interface:
For example
This is the intermediate API
#type=“projection=lambert, varphi_0=45, k=1”
type=“projection=UTM, zone=30, false_east=40000”
prj=Projection.new(type)
[x,y]=prj.geodetic_to_projected(lambda,phi)
[lambda,phi]=prj.projected_to_geodetic(x,y)
This is an especific API for UTM:
parameters=UtmParameters.new
parameters.zone=30
parameters.false_east=30
prj=UtmProjection.new(parameters)
[x,y]=prj.utm_geodetic_to_projected(lambda,phi)
[lambda,phi]=prj.utm_projected_to_geodetic(x,y)
This is an especific API for lambert:
parameters=LambertParameters.new
parameters.varphi_0=30
parameters.k=1
prj=LambertProjection.new(parameters)
[x,y]=prj.lambert_geodetic_to_projected(lambda,phi)
[lambda,phi]=prj.lambert_projected_to_geodetic(x,y)
I have used the proj.4 C library and they used pointers to functions in
C, in a offuscated code.
proj.4 use a text file like this:
“projection=lambert, varphi_0=45, k=1”
Every projection is an module (ANSI C file) and a only modulo know what
module call using the text file. There are 170 different projections.
+proj=cea +lon_0=Central Meridian
+lat_ts=Standard Parallel
+x_0=False Easting
+y_0=False Northing
+proj=lcc +lat_1=Latitude of natural origin
+lon_0=Longitude of natural origin
+k_0=Scale factor at natural origin
+x_0=False Origin Easting
+y_0=False Origin Northing
+proj=tmerc +lat_0=Latitude of natural origin
+lon_0=Longitude of natural origin
+k=Scale factor at natural origin
+x_0=False Easting
+y_0=False Northing
…
I was going to also suggest the module approach. But I do wonder why
Martin chose to call it “inverse OOP”. It seems the more appropriate
term would be “multiple inheritance” or am I missing something?
Okay. then this is a multiple inheritance problem??
On 24 Apr 2008, at 22:45, Martin V. wrote:
Okay. then this is a multiple inheritance problem??
I hate telling other people how to code, but yes it looks very much
like a multiple inheritance problem.
Ellie
raise ArgumentError unless @reality.responds_to? :reason
On 24 Apr 2008, at 22:25, Robert K. wrote:
What exactly do you mean by “intermediate”? Do you mean that all
projections should have the same interface? For that you do not
need inheritance at all - at least in Ruby. Or do you rather mean
that they share behavior (implementation)?All map proyections have the same methods (geodetic_to_projected and
projected_to_geodetic)
Then define either a projection class from which they all inherit,
or a projection module which they all include.
And if these functions are included from a module their names should
be to_projected and to_geodetic as it doesn’t matter to other classes
what they’re being translated from.
Nice reading from you again, Ellie.
Damn, I’ve gone and blown my anonymity again 
I was going to also suggest the module approach. But I do wonder
why Martin chose to call it “inverse OOP”. It seems the more
appropriate term would be “multiple inheritance” or am I missing
something?
That was my reaction. I did a lot of similar work many years ago when
I was a VB hacker and abstracted projections using interfaces, which
are marginally similar to Ruby’s modules, but it’s possible Martin has
some more complicated use case in mind.
Ellie
raise ArgumentError unless @reality.responds_to? :reason
Thanks all hehe
On 25.04.2008 03:25, Eleanor McHugh wrote:
On 24 Apr 2008, at 22:45, Martin V. wrote:
Okay. then this is a multiple inheritance problem??
I hate telling other people how to code, but yes it looks very much
like a multiple inheritance problem.
In fact, wasn’t that exactly what Martin mentioned in his first posting:
a class that inherits from multiple parents? So basically MI is just
the name for what he described in the first place.
Kind regards
robert
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs