fxruby users - Feb 2006 - Inheritance

Hi,
I want to create an object from data I have no idea which type it is. Assuming 
I have the possibilities to have an date and an int. Now I want to create 
from both an object that has the the same capabilities (e.g. show itself in a 
parent FXFrame). But there should be specific things for the different data 
types to be modified (the textfield for the int should just allow numbers and 
the textfield of the date should allow numbers and ":" and there
should be a
button beside it which pops up a FXCalendar Dialog). what I want is basically 
to create a class (lets call it Data), which has a constructor which figures 
out from which class (DateVis or IntVis) itself should inherit. Something 
like this:

class Data
	def initialize(d)
		if d.class == "Fixnum"
			inherit from IntVis
		elsif d.class == "Date"
			inherit from DateVis
		end
	end
end 

I don''t get it done. Does anybody have a clue if this is possible? Kind
of
inheritance after the fact of creation?

Thanks
Uwe

-- 
***********************************************************************
Uwe Hartl                                e-mail: Uwe.Hartl at gmx.net
91522 Ansbach                            Telephone: (0981) 9724526
Am M?hlfeld 8                            Notfall-Mobil: (0160)90418680
Germany
***********************************************************************

Uwe Hartl wrote:
> Hi,
> I want to create an object from data I have no idea which type it is.
Assuming
> I have the possibilities to have an date and an int. Now I want to create 
> from both an object that has the the same capabilities (e.g. show itself in
a
> parent FXFrame). But there should be specific things for the different data
> types to be modified (the textfield for the int should just allow numbers
and
> the textfield of the date should allow numbers and ":" and there
should be a
> button beside it which pops up a FXCalendar Dialog). what I want is
basically
> to create a class (lets call it Data), which has a constructor which
figures
> out from which class (DateVis or IntVis) itself should inherit. Something 
> like this:
> 
> class Data
> 	def initialize(d)
> 		if d.class == "Fixnum"
> 			inherit from IntVis
> 		elsif d.class == "Date"
> 			inherit from DateVis
> 		end
> 	end
> end 
> 
> I don''t get it done. Does anybody have a clue if this is possible?
Kind of
> inheritance after the fact of creation?
> 
> Thanks
> Uwe
> 
Two suggestions:

1) use modules and extend. Replace "inherit from IntVis" with

     d.extend IntVis

2) use a "factory" class and some subclasses:

     class Data
       def self.new_from_value(d)
         case value
         when Fixnum; DataFixNum.new
         when Date; ....
       end
     end

-- 
        vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

On 2/9/06, Uwe Hartl <uwe.hartl at gmx.net> wrote:
> Hi,
> I want to create an object from data I have no idea which type it is.
Assuming
> I have the possibilities to have an date and an int. Now I want to create
> from both an object that has the the same capabilities (e.g. show itself in
a
> parent FXFrame). But there should be specific things for the different data
> types to be modified (the textfield for the int should just allow numbers
and
> the textfield of the date should allow numbers and ":" and there
should be a
> button beside it which pops up a FXCalendar Dialog). what I want is
basically
> to create a class (lets call it Data), which has a constructor which
figures
> out from which class (DateVis or IntVis) itself should inherit. Something
> like this:
>
> class Data
>         def initialize(d)
>                 if d.class == "Fixnum"
>                         inherit from IntVis
>                 elsif d.class == "Date"
>                         inherit from DateVis
>                 end
>         end
> end
>
> I don''t get it done. Does anybody have a clue if this is possible?
Kind of
> inheritance after the fact of creation?
>
use the MVC pattern! don''t mix data and view classes (allthough fox did
it)
when you want to display your data instantiate the apropriate view to
display it.
you may have a FixnumView class and a DateView class which listen to
changes in the data and display it.

just my 2 cents,
-- henon

(I don''t think Uwe''s message showed up here because he cc-ed
the list.)

Uwe Hartl wrote:
> Hi Joel,
> Thank you very much. It works like a charm!
> I have chosen the "factory" approach, because there I can inherit
my
> DataFixNum from other classes:
> 
> class DataFixNum
> 	def print
> 		puts "I am a DataFixNum!   " + self.to_s
> 	end
> end
> class DataTime
> 	def print
> 		puts "I am a DataTime!   " + self.to_s
> 	end
> end
> class Data
> 	def self.new(value)
> 		case value
> 			when Fixnum; DataFixNum.new
> 			when Time; DataTime.new
> 		end
> 	end
> end
> Data.new(23).print
> Data.new(Time.now).print
> 
> 
> Is there a particular reason why I should not use "new" here
instead of
> "self.new_from_value(d)" as you suggested?
You could do that too. I guess it would prevent actually instantiating
the base class, Data, but that may be ok.

-- 
      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Hi Joel,
Thank you very much. It works like a charm!
I have chosen the "factory" approach, because there I can inherit my 
DataFixNum from other classes:

class DataFixNum
	def print
		puts "I am a DataFixNum!   " + self.to_s
	end
end
class DataTime
	def print
		puts "I am a DataTime!   " + self.to_s
	end
end
class Data
	def self.new(value)
		case value
			when Fixnum; DataFixNum.new
			when Time; DataTime.new
		end
	end
end
Data.new(23).print
Data.new(Time.now).print


Is there a particular reason why I should not use "new" here instead
of
"self.new_from_value(d)" as you suggested?

Thanks again

Uwe


On Thursday 09 February 2006 20:58, Joel VanderWerf
wrote:
> ? ? ?class Data
> ? ? ? ?def self.new_from_value(d)
> ? ? ? ? ?case value
> ? ? ? ? ?when Fixnum; DataFixNum.new
> ? ? ? ? ?when Date; ....
> ? ? ? ?end
> ? ? ?end
-- 
***********************************************************************
Uwe Hartl                                e-mail: Uwe.Hartl at gmx.net
91522 Ansbach                            Telephone: (0981) 9724526
Am M?hlfeld 8                            Notfall-Mobil: (0160)90418680
Germany
***********************************************************************

Hi henon,

I derived my idea to do it this way from this article:
http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox_p.html
http://www.javaworld.com/javaworld/jw-09-1999/jw-09-toolbox.html

I like the ideas of this guy and try to follow it through. How do you think 
about it after all? I managed (until now) that each layer of my application 
does not know anything of the data in another object. Interaction always 
takes place within the same object. The one layer which needs to show some 
informations does have an "information object" and asks it to show
itself at
a thertain space ("Like take this frame and display yourself"). How
the
information object does this: don''t care. This means complete
encasulation.
My question came from the point, the database deliveres an object from a 
query and this is the smallest atom of data I want to handle. These should 
look from the outside just like data-objects. But internal it needs to know, 
what it can do. Since I started with Ruby to be honest a couple weeks ago 
(three or four) I am not really fluent (yet).

Thanks for the hint anyways, I would like to hear what you think about the 
articles mentioned above. I did not bounce this off anybody jet, I just 
started to try it.

Thanks
Uwe



> use the MVC pattern! don''t mix data and view classes (allthough
fox did it)
> when you want to display your data instantiate the apropriate view to
> display it.
> you may have a FixnumView class and a DateView class which listen to
> changes in the data and display it.
>
> just my 2 cents,
> -- henon

Thank you very much and sorry for forgetting the cc.
Understood. I think I don''t care about the Data instantiation, since
the
classes (DataFixNum, DataTime) inherit from a common base class which 
provides a common "interface" for both. So lets be the Data class of 
temporary nature.

Uwe
> > Is there a particular reason why I should not use "new" here
instead of
> > "self.new_from_value(d)" as you suggested?
>
> You could do that too. I guess it would prevent actually instantiating
> the base class, Data, but that may be ok.

Hi Uwe,

you wrote:
> I derived my idea to do it this way from this article:
> http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox_p.html
> http://www.javaworld.com/javaworld/jw-09-1999/jw-09-toolbox.html
>
> I like the ideas of this guy and try to follow it through. How do you
think
> about it after all?
I don''t agree in seveal points. Two examples:
> get and set functions are evil
In UML you have something called "stereotype" of a class. How much
sense
getters and setters make depends of the main purpose of an object. A minimal
entity object has no interface but getters and setters. The common mistake
of OO beginners is to think that the instance variables of a class define
the attributes of the class. This is not true. The getters and setters
describe the attributes. Instance variables are a means to store the data
which is needed to implement the getters and setters and the rest of an
objects interface.
> MVC is okay for implementing little things like buttons,
> but it fails miserably as an application-level architecture.
The model of an application window models the behavour of the window. You
will of course need need a domain-model in addition to the
application-model. This is not a problem with MVC but a problem with people
misunderstanding MVC.

Be suspicious if someone with a C++ and Java background trys to explain OO
to you. In addition to this the author tells you that everybody else is
wrong and he himself has got it right.

Cheers
Sascha

On 2/11/06, Sascha Dordelmann <sdruby at onlinehome.de>
wrote:
> Hi Uwe,
[...]
>
> > MVC is okay for implementing little things like buttons,
> > but it fails miserably as an application-level architecture.
>
> The model of an application window models the behavour of the window. You
> will of course need need a domain-model in addition to the
> application-model. This is not a problem with MVC but a problem with people
> misunderstanding MVC.
i agree to that. MVC scales well to the application level when applied
recursively.
>
> Be suspicious if someone with a C++ and Java background trys to explain OO
> to you. In addition to this the author tells you that everybody else is
> wrong and he himself has got it right.
yes. the motivation for his approach (encapsulating functionality that
deals with the data into the data object) is maintainability. the
concept works only for his example (changing the type of data) but it
doesn''t scale well on large systems. imagine adding new functionality
to the system. every concerned object would have to be extended and
the functionality would be scattered over all data objects which may
result in a maintainance horror.

I don''t think that there is one right way to do the object
decomposition of a system. there are several alternatives each of them
with their specific tradeoffs.

-- henon