Asp Forum - tagged unions and instantiating objects

parisnight

3/27/2006 3:15:00 PM

I frequently work on binary data files that contain data structures
with nested tagged unions: sf2, mp3, smf, CAN, J1939. I can parse the
files ad-hoc and look at data bytes to instantiate the correct final
object but it seems there should be a better classy way where the
parsing occurs hierarchically as the inheriting classes become more
specialized.

Say a file contains a collection of shapes. As you read bytes you
discover the shapes are squares and triangles, but you don't know that
until you've read some of the data that resides in the shape
superclass, so then you have to pass that data in when you instantiate
the new square object which is then used to assign to instance
variables of the superclass. It would be nicer to be able to
instantiate a generic superclass object, read its data, then based on
the values of the tags specialize the object to become a square or
triangular object and then the specialized object can read its data to
become more specific, and so on. Each child class could parse the bits
it knows about, and the object becomes more specialized as it reads
more.
In CLOS there are ways around this such as described in Peter Seibel's
book.

Does anyone know of any Ruby techniques that work well when reading
data containing tagged unions?

Thanks! Bob

9 Answers

Ara.T.Howard

3/27/2006 4:26:00 PM

Robert Dober

3/27/2006 4:42:00 PM

On 3/27/06, parisnight@gmail.com <parisnight@gmail.com> wrote:
>
> It would be nicer to be able to
> instantiate a generic superclass object, read its data, then based on
> the values of the tags specialize the object to become a square or
> triangular object and then the specialized object can read its data to
> become more specific, and so on. Each child class could parse the bits
> it knows about, and the object becomes more specialized as it reads
> more.
> In CLOS there are ways around this such as described in Peter Seibel's
> book.
>
> Does anyone know of any Ruby techniques that work well when reading
> data containing tagged unions?
>
> Thanks! Bob

Hmm maybe I did not understand your request completely but the following
seems a reasonable approach to me

Allow an object of the superclass to be passed into the constructor of the
subclass.

-------------------------------------9<-----------------------------
class Shape
attr :nodes, :info

def initialize( info, nodes = nil )
@nodes = nodes
...
def size ...
end
end

class Rectangle
attr_accessor :width, :height
def initialize( aShape, width, height )
nodes = comp( width, height)
super "rectangle", nodes
@width = width
...
end
end

now you start reading
myShape = Shape.new( :bla )
discovery is done
myShape = Rectangle.new( myShape, 42, 27 )
------------------------------->6------------------------------

but maybe my understanding of the problem is too superficial.

Robert

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

parisnight

3/27/2006 8:03:00 PM

Oh, I see, so module almost serves purpose of an abstract class. Can
instance variables be assigned in self.new which are then carried into
TypeB without explicitly passing them? I think that may be done in
Lisp with-slots of the abstract class. mmap is convenient and acts as
a global variable to permit access to previously read numbers while
deep in the parser. Wouldn't it look nicer to simply fill the slots in
the abstract class with the numbers in the header while you have them,
more like

module Type
def self.new buf
@version = parse_byte buf # save some header info, alas,
invisible to TypeA
byte = parse_byte buf
case byte
when 0
TypeA.new buf
when 1
TypeB.new buf
end
end
end

And have TypeA or TypeB inherit those slots that are already filled.
Alas, the final instance can't see @version. Sure you can pass the
data into the instantiation or use mmap, but it seems cleaner if you
could simply bind it in the abstract header class where it naturally
belongs.

Kind regards, Bob Anderson
PS. I admire your Ruby work and writings!

parisnight

3/27/2006 8:44:00 PM

Passing in the parent instance to the child is a nice approach. In the
end they still seem like separate entities though. That is, the parent
is an object that the child can look at but the child hasn't actually
become the parent. I'd like the child to become the parent including
all its previous attributes, good or otherwise.

You read a header and it says, I'm a shape at position (4,5). So you
instantiate a shape at position (4,5). Now you read further and it
says it is a square. You'd now like the shape to change its class to
become a square with its additional attributes.

The way I've always followed is just to wait until later in the parsing
until knowing exactly what kind of an object you want to instantiate
and than using mmap or other ways to expose previously read data. But
what if there is a lot of data in the header and what if the unions are
nested. What about a more complex example like an animal or plant
phyla or taxon where there are many levels. It seems there should be a
way to refine an object's classification as more detail is discovered
about it, and it seems that each level of classification should only
need to know about the next level below it. The knowledge for
classification is contained within the class structure and
instantiation rather than in something external to the classes.

Kind regards,
Bob Anderson

Ara.T.Howard

3/27/2006 10:28:00 PM

Robert Dober

3/28/2006 8:50:00 AM

On 3/27/06, parisnight@gmail.com <parisnight@gmail.com> wrote:
>
> Passing in the parent instance to the child is a nice approach. In the
> end they still seem like separate entities though. That is, the parent
> is an object that the child can look at but the child hasn't actually
> become the parent. I'd like the child to become the parent including
> all its previous attributes, good or otherwise.

I am afraid that is not possible, remember that you have only a reference to
an object
changing the class of an existing object does not seem possible to me, but
maybe I am wrong, well I would be happy to be wrong BTW.

You read a header and it says, I'm a shape at position (4,5). So you
> instantiate a shape at position (4,5). Now you read further and it
> says it is a square. You'd now like the shape to change its class to
> become a square with its additional attributes.

Maybe I am caught in the Ruby Object Model paradigm, maybe we should forget
about objects and do our own design, seems a long shot to me though. I
noticed only *now* that you did not use classes but modules, why not,
interesting!

Nevertheless I still see the hurdle of an object not beeing able to change
its class, you can, however act on an object by defining instance variables
and methods as you read on and get more specific information.
Too bad I do not have enough time, seems quite interresting.

Cheers
Robert

>
>
>
>

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

parisnight

3/28/2006 7:42:00 PM

Thanks for all the suggestions. Although we can extend an object
freely and dynamically by adding singletons, delegates, mixins,
instance vaiables etc, its fundamental object.class is always as it was
when it was born with Class.new. We can still use modules or our own
designs to implement a more customized system for organizing objects
that are not as easily expressed directly. Sometimes simple languages
like c seem appealing again ;).
Bob

benjohn

3/28/2006 10:23:00 PM

On 28 Mar 2006, at 20:43, parisnight@gmail.com wrote:

> Thanks for all the suggestions. Although we can extend an object
> freely and dynamically by adding singletons, delegates, mixins,
> instance vaiables etc, its fundamental object.class is always as it
> was
> when it was born with Class.new.

Unless you take a look at delegate :)

> We can still use modules or our own
> designs to implement a more customized system for organizing objects
> that are not as easily expressed directly. Sometimes simple languages
> like c seem appealing again ;).

...

*ponders*

No WAY! :)

parisnight

3/29/2006 2:15:00 PM

I don't know delegate well but it looks like the original object and
the delegated object are separate entities, i.e. instance variables and
methods are still distinct.

I noticed that if the klass pointer could be changed then the object
would really become of a different class, but I don't know enough about
how the methods and instance variables are indexed and if the child
inheritor would be able to access them safely.

Lisp CLOS objects can change class easily, I just hesitated to mention
lisp, so I chose c instead :)

comp.lang.ruby

tagged unions and instantiating objects

parisnight

Ara.T.Howard

Robert Dober

parisnight

parisnight

Ara.T.Howard

Robert Dober

parisnight

benjohn

parisnight

x Login to ForumsZone