behaviour vs. data first
in [OOP]
|
Prev: Informatics 2010: 1st call extension - 30 April 2010
Next: The Eiffel Compiler tecomp version 0.22 released
From: S Perryman on 19 Apr 2010 08:50 Dmitry A. Kazakov wrote: > On Sun, 18 Apr 2010 16:59:15 +0100, S Perryman wrote: >>Dmitry A. Kazakov wrote: >>With dynamic linking, the basic concept is that when use of an entity is >>required, the loading process either finds the entity, or does not. >>The overall program then continues to execute, or fails. > It is not that simple. It most certainly is. > There reason to fail must be all on the caller's > side. I.e. it can fail if I do something wrong, e.g. trying to bind to a > non-existent entity. The problem with failed consistency checks is that it > can fail because of something I cannot/will not control/foresee. Then you must submit to the static "closed world assumptions" view. If there is an unsupported implementation for an actual M/input/output instance, that is a defect. When you want that defect to be revealed, and what you are prepared to give in order for that moment to come as soon as possible, is your choice. You cannot have it all ways. Tis interesting to me as to what the middle ground is or might be. Or in a semi-precise mathematical form, forall : - program = P - T(P) = the type information that allows proof that no multiple dispatch defects exist in P Then for an incremental addition to P involving program unit U (program = P+U) : What are the contents of T(P) , T(U) , T(P+U) ?? > This is somewhat similar to loading libraries of incompatible versions, but much > worse. Most likely I will have no slightest idea what the problem is. One > library provides a new printer, another does a new shape, and I, the end > user, cannot use them together even if I don't use the missing combination. > Even worse, if I don't print anything, but there is a third library that > does, it won't load. That looks like a maintenance disaster. It adds another dimension into the realms of possible defect causes. But only for the 'dynamic loading' scenario. Regards, Steven Perryman
From: S Perryman on 19 Apr 2010 09:11 Nilone wrote: > On Apr 18, 10:57 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >>Tuples, arrays and records are classic examples of container types. > They're how containers have classically been implemented. I see a > container as an ADT which accepts and returns objects. Tuples (aka > records), arrays and relations are data structures, i.e. they're just > ways of logically arranging things. Give examples of all the types of "containers" that you believe to exist in the mainstream world of software development. Based on the above, I contend that there is only one type of container in your world. Regards, Steven Perryman
From: Dmitry A. Kazakov on 19 Apr 2010 09:45 On Mon, 19 Apr 2010 13:50:42 +0100, S Perryman wrote: > If there is an unsupported implementation for an actual M/input/output > instance, that is a defect. Only if that implementation is ever called. If we knew statically that it is not called, we could safely ignore the defect. > Tis interesting to me as to what the middle ground is or might be. > Or in a semi-precise mathematical form, forall : > > - program = P > - T(P) = the type information that allows proof that no multiple dispatch > defects exist in P > > Then for an incremental addition to P involving program unit U > (program = P+U) : > > What are the contents of T(P) , T(U) , T(P+U) ?? If T(U) then for P+U it must be shown that there is no contexts where any two types causing a defect can be both instantiated. I don't see it as an insuperable obstacle in a manifestedly typed language. What puzzles me is how to provide necessary implementations. The problem is that the offending types from P and U are already frozen in P+U. It is too late to override anything there. [It is the issue of the last point where new methods can be added to an interface. It cannot be anywhere, not before the first type use.] There should be some graceful solution to that. >> This is somewhat similar to loading libraries of incompatible versions, but much >> worse. Most likely I will have no slightest idea what the problem is. One >> library provides a new printer, another does a new shape, and I, the end >> user, cannot use them together even if I don't use the missing combination. >> Even worse, if I don't print anything, but there is a third library that >> does, it won't load. That looks like a maintenance disaster. > > It adds another dimension into the realms of possible defect causes. > But only for the 'dynamic loading' scenario. Even if loaded components have statically known interfaces? That sounds very disappointing. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Nilone on 19 Apr 2010 13:10 On Apr 19, 3:11 pm, S Perryman <a...(a)a.net> wrote: > Nilone wrote: > > On Apr 18, 10:57 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > > wrote: > >>Tuples, arrays and records are classic examples of container types. > > They're how containers have classically been implemented. I see a > > container as an ADT which accepts and returns objects. Tuples (aka > > records), arrays and relations are data structures, i.e. they're just > > ways of logically arranging things. > > Give examples of all the types of "containers" that you believe to exist > in the mainstream world of software development. > > Based on the above, I contend that there is only one type of container in > your world. It seems to me the whole notion of containers is problematic in OO. A particular collection type may promise to return what you passed to it, in some particular order or in response to some message, and we can try to categorize the different behavioural profiles based on familiar structures, but there's really nothing that constrains OO types to conform to some or other category. Mixed paradigm languages may allow or require such constraints, but I wouldn't call it OO features. In languages which include the concept of data, there are numerous different structures and ADTs which can be used to create variables. http://en.wikipedia.org/wiki/List_of_data_structures is a good start. I think it requires a mixed paradigm to call such structured variables container objects.
From: S Perryman on 19 Apr 2010 14:23
Nilone wrote: > [ snipped - but read ] All very nice, but irrelevant to my query. Give examples of all the types of "containers" that you believe to exist in the mainstream world of software development. Once you can tell us what you consider to be "containers" , then I can scrutinise other things you have written in your debate on the topic. If you are struggling to do so, here is something I consider to be a "container" : sets. Hopefully that will propel you to give other examples that satisfy your definition. Regards, Steven Perryman |