Re: Child objects inheriting property values

> 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.

Excel 2007 fixes this problem


-----Original Message-----
From: Discussion of development on the .NET platform using any managed
language [mailto:[email protected]] On Behalf Of Julian
Lawrence
Sent: Friday, November 23, 2007 6: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 DevelopMentor.  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