Re: Child objects inheriting property values

> On Behalf Of Peter Obiefuna
> Sent: Saturday, 24 November 2007 1:21 PM
> To: [email protected]
> Subject: Re: [DOTNET-CLR] Child objects inheriting property values
>
>
> Just so as not to spin off too deeply beyond the original
> issue: I think we can both agree that domain assumptions have
> to be made for a model to correctly abstract a problem in
> that domain.

Yes. I suspect "how do I abstract" is a bit deep for now. However, I
believe there is usually more than one "correct" abstraction there is
often only one "acceptable" abstraction.

> As far as the original question went, I think
> our assumptions are correct as they apply to the relational
> model that the question portrayed. You can indeed conjecture
> the possibility of that model being too limited for data
> quantization in the 'string theory of everything' but that is
> a little beyond the scope of the original question and cannot
> help that original contributor to build his app for waiting clients.

I think we got to this bit of the discussion when I felt we were at risk
of constraining the language to support a particular current way of
thinking. While compiler constraints are necessary they must be
introduced with great care and forethought. There is a necessary balance
between the need to constrain the compiler to support currently accepted
patterns, using the language to guide good practice, and the potential
loss of flexibility to explore new, possibly as yet unkown, patterns.

Apart from the context of the original question I suspect the digression
into columns and rows occured as just one example of where a particular
paradigm may be used to introduce significant constraints into a
language and potentially lock out the application to other paradigms.

> Just an aside: I think a record as a collection of cells is
> not a simple model. Take the rowID for instance: Is it the
> record ID or the cell1ID_rowID or cell2_rowID ... or
> celln_rowID? What if you want to relocate the record ...
> you'd start iterating all the cells and start relocating them
> one after another. That, to say the least is bad software
> engineering because there is a model that simplifies the
> problem. A model shouldn't only be just another abstraction.
> It should be an abstraction of a problem that aims to simplify it. P

Definitely an aside. It wasn't as hard as I thought before I started. As
it unfolded it became ever more simple, a useful clue that something may
be workable. Following is really just a few insights.

To put it into perspective, it took me about 10 years to comprehend some
of the concepts behind object oriented (I'm not an expert and I'm not
finished), it took my daughter about 10 minutes. Such is the
intellectual cost of prior knowledge and paradigms. The following was
intellectually demanding to say the least.

But here goes.

Rows is a collection (broadest sense) of Rows. Row is a collection of
cells (call it cell collection for this monologue). Column is an
instance of the same class as row. As are the next several dimensions.
The interesting bit is the cell needs a reference to the row. In fact,
it has a collection of cell collections so it knows where it is in all
dimensions. Moving a row is simply a case of moving the row within the
collection of rows. The row ID is largely irrelevant as the whole
structure is maintained by reference (belated thanks for all the
discussions in this forum about by reference and by value) rather than
an index or foreign key. Moving a block of cells bounded by part of
several rows and part of several columns (and part of several...more
dimensions) is a bit mind bending but is surprisingly symmetrical and
can be about moving values and changing references, not cells. Sorting
on a column is simply sort the rows collection on the values of the
cells in the column cell collection and present the different sequence
of rows from the row cell collection. Sorting on a row (as for any
dimension) is identical to sorting on a column (simple, it's an instance
of the same class! :-) ). Etc.

Pleased to see Excel fixed the limit on rows and columns. Being greedy,
as a user, I now need a row sort, and a page sort, and a ..... sort, and
a column filter....., and a! Just as I expect from my database.
Rhetorically, how many times have I seen people construct a spreadsheet
then have to transpose it and still not get quite what they wanted? Back
to the top, perhaps unkindly, but it's a useful example, either the
problem domain was inadequately abstracted, the computer and language
capability at the time of writing version 1 were limited,  commercial
reality impinged, or any combination of those and other constraints
(anyone else familiar with theory of constraints?). To be positive,
something like the .Net framework allows a different approach to the
innards of something like spreadsheets. It allows a more easily visible
pathway from "I don't like it" to "this is how it could be improved".

Data type, format, etc. are not properties of one dimension (database
column), they are properties of the cell. Not as bad as it sounds, only
the bit we see on the screen is visited during repaint not all cells.
Across (columns) and down (rows) becomes purely a screen concept rather
than a data storage concept. Scrolling is just as fast as it ever was.

Having established the concept of cells there are forward and backward
references to other cells, imagine a network of cells. Recursive
traversals of the cell network can be made. Only some relational
databases handle recursive tree structures, I'm looking for the memory
resident database that handles cyclic network structures. The cell
network may be sparesly populated - not all cells have to exist - the
empty space on the screen is a screen concept.

The class structure can get interesting. One might imagine that there
are Rows, Row and Cell. It was worthwhile having just a universal thing
(struggled with the name for such an abstraction but dimension begins to
get there) used recursively. Sounds bizarre, but that gets us part way
back to the unique id for the row and the relationships to rows in other
"tables". Or, between columns, or any other dimension. In one sense, its
really just the same as a relationship between cells. At this point one
can hopefully perceive why I was so interested in the subject of the
original question. I could conceive of the same or different delimiters
for any or all dimensions in different contexts.

The original problem domain recognised the conceptual similarities
(rather than differences) between a flowchart (many different forms), a
set of database tables and a spreadsheet. A node in a flowchart may be
considered the same as a row or a cell in the spreadsheet, just has a
bit more spatial info than row height or column width and the link may
have data. The presentation is just a little different. The project was
defined initially as a research project without a foundation customer to
deliberately escape the commercial time pressures and specific real
world constraints but with the recognition that would come later.

Genesis was about 15 years ago, as a user (I've switched career tracks
several times). I got fed up paying several people to maintain bill of
material and routing structures one link (database row) at a time and
not having all the modelling capabilities required. Reductionism can be
our enemy and result in overall grossly inefficient systems - there were
only about 100 pieces of data but the system drove us to maintain about
15,000 (a moderately well understood and documented problem among some
users of ERP systems which vendors have seemed reluctant to address -
the digital cement has well and truly set).

Of course this object based approach is impractical based on disk
storage for manipulation because of the latency in the disk for
non-contiguous data storage. But in memory it all flies along very well.
One outcome is it reduces the database to being persistent storage for
the data rather than a presenter of data. Isn't there ORM somewhere
(though re-building the object graph from database is very painful). Or
give me an abstracted database front end or a different type of
database!

Sorry again, its not commercially available.

And the disclaimer. I accept that all this may be perceived as the
ramblings of a deranged mind, I'm comfortable with that. I'm absoltuely
not trying to convince anyone that what they are doing is "wrong", just
suggesting that there are viable alternative "rights".

Importantly though, please don't constrain the compiler too much as that
may drive me to a different technology stack.

>
> --------------------------------------------------
> From: "Julian Lawrence" <[email protected]>
> Sent: Friday, November 23, 2007 5:03 PM
> To: <[email protected]>
> Subject: Re: [DOTNET-CLR] Child objects inheriting property values
>
> > "one would logically create a structured record"
> >
> > That may be learned problem solving behaviour (good though it is)
> > rather than logic.
> >
> > "Moreover, a record cannot be a type of a column or vise versa."
> >
> > That's correct ..... in a row oriented database paradigm......
> >
> > In a different paradigm, with a different abstraction, a
> record (row)
> > may be considered just a collection (in its broadest sense)
> of cells
> > (or fields, or whatever name they happen to have). Column
> and Row can
> > be simply different instances of the same class. As can be
> collections
> > of columns and rows. They can be called dimension1 and
> dimension2 or
> > something else, and so on into several dimensions (I think the
> > spreadsheet calls the third one sheet and the fourth one file).
> >
> > Data storage on a (2-Dimensional) disk is not pretty as the typical
> > database insists on records and fields, but the
> (n-Dimensional) memory
> > resident "database" works well. Specially with sparse networks of
> > data. How rows and columns are mapped to the
> (2-Dimensional) screen is
> > flexible.
> >
> > It always intrigued me as to why an Excel spreadsheet is limited to
> > 255 columns wide by 65535 rows deep - must be a lot of
> baggage / lack
> > of abstraction in there somewhere. Those of us who live in
> countries
> > with the post code called something other than zip code experience
> > another lack of abstraction on a daily basis.
> >
> > Not quite the same, but in a different paradigm again, there are
> > column oriented databases.
> >
> > Anyway, enough of the detail, the issue is abstraction which occurs
> > somewhere in design. Refactoring a system may lead to changing the
> > abstraction.
> >
> > Nothing magic. The Biological example is every so often someone
> > decides definitions of species need changing to aggregate or
> > disaggregate as the taxonomy becomes unmanageable, or recent Space
> > example of redefining planets. The rows, columns, my
> address, animals,
> > plants and celestial bodies don't change, just how we
> define and model
> > them.
> >
> > Sorry for drifting a little off topic.
> >
> >> -----Original Message-----
> >> From: Discussion of development on the .NET platform using any
> >> managed language [mailto:[email protected]]
> >> On Behalf Of Peter Obiefuna
> >> Sent: Saturday, 24 November 2007 7:19 AM
> >> To: [email protected]
> >> Subject: Re: [DOTNET-CLR] Child objects inheriting property values
> >>
> >>
> >> You would be right Ryan if you are describing the 'inheriting'  of
> >> property values. Not the explicit assignment of a value in
> a base to
> >> its child. Well, Julian, it actually matters where the value comes
> >> from. Because all you'd need to do is to have only one protected
> >> field in the base with an initial value. You need not have another
> >> property of the same name in the inheriting object.
> >>
> >> instead of
> >>
> >> this.delimiter = base.delimiter;
> >>
> >> just have a
> >> protected string delimiter = "<default_delimiter>";  // and you're
> >> done.
> >>
> >> Julian raises an interesting twist with the concept of columns and
> >> records and does not think that any of the two has to be
> semantically
> >> more upstream than the other. I'll like to hear more on
> that. I hope
> >> we commonly agree that every model has to be based on some
> assumption
> >> of domain context for it to have semantic relevance to the
> problem it
> >> tries to solve. And our assumption is that a record of facts
> >> is an aggregate collection of fields
> >> (columns) of information that comprise that record (like on a
> >> paper form). Even in a spreadsheet, a cell can be an
> >> intersection of a column and a row. But once you talk about a
> >> record, whether on a paper file or on a database or excel or
> >> cobol data structures, you would logically create a
> >> structured record after you have first carved out the fields
> >> (columns) on the form. Moreover, a record cannot be a type of
> >> a column or vise versa.
> >>
> >> Please tell us what we are missing.
> >> P
> >>
> >>
> >> --------------------------------------------------
> >> From: "Julian Lawrence" <[email protected]>
> >> Sent: Friday, November 23, 2007 11:53 AM
> >> To: <[email protected]>
> >> Subject: Re: [DOTNET-CLR] Child objects inheriting property values
> >>
> >> > Fascinating question.
> >> >
> >> > It seems to me that there's a considerable conceptual difference
> >> > between inheriting properties and inheriting values of
> properties.
> >> >
> >> > Class inheritance isn't always an indicator of the sequence
> >> in which
> >> > classes should be instantiated.
> >> >
> >> > During instantiation it really shouldn't matter where the
> >> value of a
> >> > property comes from. If it happens to be the value of a
> >> property of an
> >> > instance of the base class or default to a value provided
> >> in the base
> >> > class during construction so be it. Why should it be
> >> disallowed in the
> >> > compiler?
> >> >
> >> > The flexibility is probably required more in abstracted
> >> than literal
> >> > models. To expand a little. The constraining idea of columns and
> >> > records is an artefact of database paradigms. To those
> who think in
> >> > spreadsheet cells, which can be grouped any which way, it
> >> may seem odd
> >> > to have to worry whether the row or the column is created first.
> >> > Nothing right or wrong or absolute about the two paradigms, just
> >> > different models, and there are others.
> >> >
> >> > The practical solutions to the question were described
> in the first
> >> > couple of posts.
> >> >
> >> > Julian
> >> >
> >> >> -----Original Message-----
> >> >> From: Discussion of development on the .NET platform using any
> >> >> managed language [mailto:[email protected]]
> >> >> On Behalf Of Ryan Rinaldi (TT)
> >> >> Sent: Saturday, 24 November 2007 1:19 AM
> >> >> To: [email protected]
> >> >> Subject: Re: [DOTNET-CLR] Child objects inheriting
> property values
> >> >>
> >> >>
> >> >> "Moreover, assigning field values of a base class to its
> >> subclass in
> >> >> a constructor feels awkward. A good compiler should
> disallow it."
> >> >>
> >> >> If any .NET compiler disallowed it ASP.NET wouldn't work!
> >> :) At least
> >> >> the older ASP.NET Web Application code-behind model.
> In the code
> >> >> behind you declare all of the controls while the .aspx page
> >> >> instantiates them.  Quite awkward and convoluted resulting
> >> in a page
> >> >> that can compile but if you forget to add the control to
> >> the page it
> >> >> crashes at runtime.
> >> >>
> >> >> -----Original Message-----
> >> >> From: Discussion of development on the .NET platform using any
> >> >> managed language [mailto:[email protected]]
> >> >> On Behalf Of Peter Obiefuna
> >> >> Sent: Wednesday, November 21, 2007 9:40 PM
> >> >> To: [email protected]
> >> >> Subject: Re: [DOTNET-CLR] Child objects inheriting
> property values
> >> >>
> >> >> Using inheritance is semantically wrong since a Column 'IS
> >> A' record
> >> >> is not correct. Moreover, assigning field values of a base
> >> class to
> >> >> its subclass in a constructor feels awkward. A good
> >> compiler should
> >> >> disallow it. Again, the class order in your question
> >> appears reversed
> >> >> to me (I expect a column collection to exist before a
> record does)
> >> >> but I'll just answer your question narrowly. Here's my
> solution to
> >> >> that problem. =======================================
> >> >>
> >> >> class Column{
> >> >>
> >> >>     private char delimiter;
> >> >>     public Column(){
> >> >>         // first, set parent record;
> >> >>         // then ...
> >> >>         this.delimiter = ParentRecord.Delimiter;
> >> >>     }
> >> >>     public Record ParentRecord { get; set; }
> >> >>     public char Delimiter { get; set; }
> >> >> }
> >> >>
> >> >> class Record{
> >> >>     private char delimiter = '^';
> >> >>     public Record(){
> >> >>
> >> >>     }
> >> >>     private Column[] columns;
> >> >>     public char Delimiter {get; set;}
> >> >>
> >> >> }
> >> >>
> >> >> --------------------------------------------------
> >> >> From: "Adrian Martin" <[email protected]>
> >> >> Sent: Tuesday, November 20, 2007 6:28 AM
> >> >> To: <[email protected]>
> >> >> Subject: Re: [DOTNET-CLR] Child objects inheriting
> property values
> >> >>
> >> >> >        class Column : Record
> >> >> >        {
> >> >> >                public Column()
> >> >> >                {
> >> >> >                        this.Delimeter = base.Delimeter;
> >> >> >                }
> >> >> >        }
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > -----Original Message-----
> >> >> > From: Discussion of development on the .NET platform using
> >> >> any managed
> >> >> > language [mailto:[email protected]] On
> >> Behalf Of Brady
> >> >> > Kelly
> >> >> > Sent: 20-November-2007 10:10
> >> >> > To: [email protected]
> >> >> > Subject: Child objects inheriting property values
> >> >> >
> >> >> > I have a hierarchy of objects that share some attributes,
> >> >> e.g. both my
> >> >> > parent Record and Column objects have a columnDelimiter
> >> >> property.  I
> >> >> > want this property on the Column object to default to
> the same
> >> >> > property on the Record object, until specified on the Column
> >> >> > object.  What
> >> >> is the best
> >> >> > way
> >> >> > to go about this?  I could give each Column a reference to
> >> >> the Record
> >> >> it
> >> >> > belongs to, but this seems not quite right to me.  My other
> >> >> option is
> >> >> to
> >> >> > have the Record act as a ColumnFactory, setting the
> >> columnDelimiter
> >> >> > value on each Column it creates, until a set accessor
> on Column
> >> >> > optionally overrides that default value.
> >> >> >
> >> >> >
> >> >> > ===================================
> >> >> > This list is hosted by DevelopMentor(r)
> http://www.develop.com
> >> >> >
> >> >> > View archives and manage your subscription(s) at
> >> >> > http://discuss.develop.com
> >> >> >
> >> >> >
> >> >> > Johnston Press plc      Registered in Scotland no. SC015382
> >> >> > Registered Office: 53 Manor Place, Edinburgh, EH3 7EG
> >> >> >
> >> >> > Opinions expressed in this email are those of the writer
> >> >> and not the
> >> >> > company.  E-mail traffic is monitored within Johnston
> Press and
> >> >> messages
> >> >> > may be viewed.  This e-mail and any files with it are
> solely for
> >> >> > the
> >> >> use
> >> >> > of the addressee(s).  If you are not the intended
> >> >> recipient, you have
> >> >> > received this e-mail in error.  Please delete it or return
> >> >> it to the
> >> >> > sender or notify us by email at [email protected]
> >> >> >
> >> >> > ===================================
> >> >> > This list is hosted by DevelopMentor(r)
http://www.develop.com
>> >> >
>> >> > View archives and manage your subscription(s) at
>> >> > http://discuss.develop.com
>> >> >
>> >>
>> >> ===================================
>> >> This list is hosted by DevelopMentor(r)  http://www.develop.com
>> >>
>> >> View archives and manage your subscription(s) at
>> > http://discuss.develop.com
>> >
>> > ===================================
>> > This list is hosted by DevelopMentorR  http://www.develop.com
>> >
>> > View archives and manage your subscription(s) at
>> > http://discuss.develop.com
>> >
>> > ===================================
>> > This list is hosted by DevelopMentorR  http://www.develop.com
>> >
>> > View archives and manage your subscription(s) at
>> > http://discuss.develop.com
>> >
>>
>> ===================================
>> This list is hosted by DevelopMentorR  http://www.develop.com
>>
>> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
> ===================================
> This list is hosted by DevelopMentorR  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>

===================================
This list is hosted by DevelopMentorR  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com