<div dir="ltr"><div class="gmail_extra">Francois,</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 5:11 AM, François Bonnarel <span dir="ltr"><<a href="mailto:francois.bonnarel@astro.unistra.fr" target="_blank">francois.bonnarel@astro.unistra.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">- Semantically a coefficient is basically just a number and
become a coefficient only in the context of polynomial. And we want
anything done for polynomials in the STC model to be independant of
the order</blockquote></div><br>I agree, although a coefficient may have both an order and a value (hence a polynomial without a coefficient for a given order would have 0 for that order).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Three important points, imo:</div><div class="gmail_extra"> * Do Coefficients have identity? I don't think so, hence I think they are DataTypes. And a Polynomial would be an Object Type (it has identity, you can refer to a particular instance of a Polynomial by its "name"... it may even be stored somewhere else) with a variable length array of Coefficients. [For the record, I think that polynomials may be Data Types just as well, but for the sake of argument I'll keep considering them Objects]<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"> * You may want to represent polynomial instances within a Java application: you would most likely use two classes: one for Polynomial, with a List<Coefficient> coefficients field, a String description field, and an ID field (maybe a URI); and one class for Coefficient, with an int attribute for the order and a double for the value. They are both java classes, but one represents an Object Type, and one represents a Data Type: the semantic difference between the two fundamental Types is not reflected by the structure you use to represent them in a specific implementation. Data Types and Object Types may both map to classes in an OO language.</div><div class="gmail_extra"><br></div><div class="gmail_extra"> * You may want to store polynomial instances within a relational database: you would most likely have two tables, one for Polynomial, with an ID column and a description column, and one table for Coefficients, without primary key, but with a column Polynomial_ID that is a foreign key pointing to the Polynomial instances, a column for the order, and a column for the value. You would also have DB constraints that dictate that when a Polynomial instance (a row in the table) is deleted, the corresponding coefficients are deleted as well, because a coefficient does not make sense, cannot exist, without the owning Polynomial, which is one of the characterizations of Data Type.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In this discussion I am arguing that there is a clear mapping, through ORM, between the Java representation of the instances (or any object-oriented language), and their representation in the database, despite the fact that Object Oriented languages and Relational Databases are intrinsically different, and often times incompatible. If I was wrong, and this mapping would not be clear, or possible at all, then my argument would fail and variable length arrays should indeed be left off the language. This is the crux of the issue, I believe.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The fact that VO-DML allows automatic data binding and code generation is a plus that may be really useful for a number of applications, and may validate the generality of the language, but it does not mean, in any possible way, that VO-DML is meant to be used exclusively for automatic generation of code. That's useful, by definition, for model-unaware applications. Model-aware applications should apply their own optimizations to efficiently represent and manipulate domain-specific instances.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Omar.</div><div class="gmail_extra"><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Omar Laurino<br>Smithsonian Astrophysical Observatory<br>Harvard-Smithsonian Center for Astrophysics<div><font color="#999999">100 Acorn Park Dr. R-377 MS-81</font></div><div><font color="#999999">02140 Cambridge, MA</font><br><span style="color:rgb(153,153,153)"><a value="+16174957227" style="color:rgb(17,85,204)">(617) 495-7227</a></span></div></div></div>
</div></div>