confusion about data abstraction
in [OOP]
|
From: Daniel Parker on 12 Dec 2006 13:42 Dmitry A. Kazakov wrote: > On 12 Dec 2006 08:20:33 -0800, Daniel Parker wrote: > > > Dmitry A. Kazakov wrote: > >> > >> We have to decide > >> whether data represented by a text value show a behavior of a date or text. > >> Consider T1 - T2, what is the result? Does < compare dates or texts? Can I > >> add "1" to the text and get the date of 1 second later? > > > > All of these things are defined in a specification. XML Schema is not > > one of the world's great specifications, but it does define all of > > these things. > > Really? It is impossible to specify one time format. The fundamental laws > of physics (relativity theory) and mathematics would prevent this. > Did I say something about one time format? I don't think I said something about one format. One of the points of document centric approaches to problems is that specifications are contextual. Sometimes that context is quite broad, such as the ISO 8601date/time specifications (as adopted by XML Schema.) > >>> Every industry from life > >>> insurance to publishing seems to be participating in consortiums for > >>> standardizing on a representation of data that fits their business > >>> context. > >> > >> This is an obvious and easy step ... in a totally wrong direction. One > >> could agree on a representation format of something which behavior is > >> known. For this you have to define the behavior. How could we do that? What > >> is the behavior of date? Has it day savings? Is it monotonic? Is it > >> astronomical time. Would it work on the moon? etc. Even for simple things > >> like floating point number it is very difficult to define the behavior of. > >> What about any more complex stuff? The point is, you need a language (not > >> necessarily a programming one) to describe the behavior. > > > > A specification will do. > > I am impressed. Can these specifications be written in XML? Depends what you mean by "written in". The text that defines the specifications can be expressed as XML markup, or plunked into an open Word document. > > >>> Communication is through the transfer of documents containing > >>> data adhering to standards. One big reason is decoupling; from a > >>> document centric approach, no matter how many code decoupling > >>> strategies Robert Martin comes up with, the result is still tightly > >>> coupled, it is in the nature of code. (I'm not exactly sure what > >>> "behaviour" means, I haven't seen the term used in formal treatments of > >>> ADTs, but I think it has something to do with code.) > >> > >> I see your point. But the decoupling you are talking about were achieved > >> through making everything static. All and everybody should agree on an > >> implied, not stated, behaviour of dates. You cannot communicate things you > >> didn't agree in advance. This is an utopia. It has no future, > > > > It has a present. Who knows about the future? > > Well, we could use COBOL. I see no any technological difference. You > propose to sit down and specify everything in the world. Great, why didn't > it worked in 70's? > I'm not proposing anything, I'm observing current practice, evolving tooling, declining interest in distributed objects, declining interest in RPC, increasing interest in messaging, declining interest in code centric approaches, increasing interest in document centric approaches, etc. The reasons for these trends seem clear enough. > > Good data > > specifications do allow for extensibility. > > Ah, that's interesting. What about a good specification of a circle? Let's > extend to an ellipse! (:-)) > Did I mention the "must ignore" principle :-) > > There is some flexibility, > > known components can be assembled in different ways, and understood. > > and then crash... > > If I were a conspiracy theorist, I would suggest that the only purpose of > XML was to rebut the Moore's law. (:-)) > > >> You lifted a local coupling and moved it > >> to the global scope, probably beyond mere software developing. Yuck. > >> > > I don't think so. CORBA, RMI etc. introduce global coupling, things > > have to match on both sides of a wire. > > This is true, but remember that CORBA was designed long ago. It lacks a > consistent type system. But for all, CORBA's approach is just like yours > with the only difference that the coupling is system-wide. IDL files are > statically valid across the system. In your approach W3C is planet-wide. > Great. > > > Communication based around > > documents with well defined data takes that out. > > The only question is why do we use computers? Document exchange worked > great in XIX century... (:-)) > Computers are very useful in a document centric world. Many years ago I worked as a policy analyst in a provincial Treasury department. Our deputy minister talked Yankee talk and our minister talked the Queen's English. The same document had to be constantly translated between English and American, depending on whose signature it was going out under. All documents written in Treasury were collected into folders and circulated throughout the department, starting with the Deputy Minister, who would read them all and circle with a red pen any translation errors, so everyone could see who had goofed. Think how this process would have benefitted from computers! Best regards, Daniel Parker http://servingxml.sourceforge.net/
From: topmind on 13 Dec 2006 01:04 Dmitry A. Kazakov wrote: > On 12 Dec 2006 09:21:37 -0800, topmind wrote: > > > In scriptish or dynamically-typed languages one gets used to this kind > > of thing and deals with it. The advantage of a standardized text > > formats is that just about any programming language can use them, at > > least in a rudimentary sense. Creating a date library for each of 2,000 > > programming languages is not good factoring of human effort. > > Which is exactly what Daniel's approach implies, you need an XML parser + > interpreter for all 2,000 languages. Use comma or pipe "|" delimited instead of or as as an alternate to XML. Pipe-delimited is easy to parse. > > > By the way, a connonical date text format can still be compared > > properly as strings if designed right. For example, a date formatted in > > YYYY-MM-DD can be compared using ">" and "<". > > I am dying to see a GPS system based on this time representation. Maybe > GALILEO will become one? The representation is not necessarily what the *user* sees. > > > I know many of you OO'ers want to force everybody into a single OOP > > language, such as Java or Smalltalk to acheive behavioral unity, but > > that is not going to happen and text is more multi-language-friendly. > > LOL. I always knew that you don't trust in DBs! (:-)) Read what you wrote. > Is it about the format for keeping the source code programs written in > those "multi-languages?" (:-)) For that purpose I'd propose a DB, like > ClearCase! I am not sure what you are talking about here. > > >> Should we do > >> natural text processing, or what? Even if we managed it perfectly, an A.I. > >> from UK could ask, damn it, is 12:00 in the text above PM or AM? > >> > >> People are doing things you are describing, just because they don't want to > >> think any further, and because any kind of more precise definition is not > >> in the economical and political interests of the parties involved. The > >> least common denominator is what we get. > > > > Bull. It is because it is more flexible. Data has outlasted programming > > languages many times. 20 years from now Java will be looked down on the > > way COBOL is. Its screwy meta model is already a laughing stock. > > I presume that COBOL is still the most used language. Yes, but nobody wants to admit to having it. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de -T-
From: Dmitry A. Kazakov on 13 Dec 2006 04:20
On 12 Dec 2006 10:42:35 -0800, Daniel Parker wrote: > Dmitry A. Kazakov wrote: >> On 12 Dec 2006 08:20:33 -0800, Daniel Parker wrote: >> >>> Dmitry A. Kazakov wrote: >>>> >>>> We have to decide >>>> whether data represented by a text value show a behavior of a date or text. >>>> Consider T1 - T2, what is the result? Does < compare dates or texts? Can I >>>> add "1" to the text and get the date of 1 second later? >>> >>> All of these things are defined in a specification. XML Schema is not >>> one of the world's great specifications, but it does define all of >>> these things. >> >> Really? It is impossible to specify one time format. The fundamental laws >> of physics (relativity theory) and mathematics would prevent this. >> > Did I say something about one time format? I don't think I said > something about one format. One of the points of document centric > approaches to problems is that specifications are contextual. And what determines the scope of a document? Let we have n time formats and corresponding behaviours. Do you allow m of them to meet in one scope? 1. What determines the time type behavior. If the scope does, then you have a nasty coupling. If it does not, then you need an object identity, and welcome back to OO! 2. What can be said about the behavior of the pair of two times in different formats? It seems to be undefined. It is a combinatorial explosion of intermixed behaviors. >>>>> Every industry from life >>>>> insurance to publishing seems to be participating in consortiums for >>>>> standardizing on a representation of data that fits their business >>>>> context. >>>> >>>> This is an obvious and easy step ... in a totally wrong direction. One >>>> could agree on a representation format of something which behavior is >>>> known. For this you have to define the behavior. How could we do that? What >>>> is the behavior of date? Has it day savings? Is it monotonic? Is it >>>> astronomical time. Would it work on the moon? etc. Even for simple things >>>> like floating point number it is very difficult to define the behavior of. >>>> What about any more complex stuff? The point is, you need a language (not >>>> necessarily a programming one) to describe the behavior. >>> >>> A specification will do. >> >> I am impressed. Can these specifications be written in XML? > > Depends what you mean by "written in". The text that defines the > specifications can be expressed as XML markup, or plunked into an open > Word document. I.e. the answer is no, it cannot. In other words the behavior is not stated, it is implied. Where is a warranty that all participants imply the same behavior? To me the idea of OO is to reduce this "depth-first" approach, where you have to define everything in advance. Let's put XML aside and go to one level up. How the eggheads at W3C committee could communicate each other. In which language they would write the documents (joyfully decorated with XML tags)? In a natural language? That would be the state of art for 70's, a pure Luddism in my view. The point is, representation (read data) is not a concern. Let it be any. Semantics is the problem OO tries to address. > I'm not proposing anything, I'm observing current practice, evolving > tooling, declining interest in distributed objects, declining interest > in RPC, increasing interest in messaging, declining interest in code > centric approaches, increasing interest in document centric approaches, > etc. Well, I don't know. I see no clear signs of what you describe. Yes, CORBA is not very popular in data acquisition. But I don't see that anybody there would have an illusion that XML could replace it. XML would be considered as a must, but never as a replacement. I could address this to the fact that XML is IMO a typical hype. Further, I saw many implementation of new ORB's. In freshmeat, I believe, just one week ago. BTW, I am not a fan of CORBA, rather the opposite. > The reasons for these trends seem clear enough. .... prevailing bad taste, you mean? (:-)) >>> Good data >>> specifications do allow for extensibility. >> >> Ah, that's interesting. What about a good specification of a circle? Let's >> extend to an ellipse! (:-)) >> > Did I mention the "must ignore" principle :-) OK, OK (:-)) >>> Communication based around >>> documents with well defined data takes that out. >> >> The only question is why do we use computers? Document exchange worked >> great in XIX century... (:-)) >> > Computers are very useful in a document centric world. Many years ago > I worked as a policy analyst in a provincial Treasury department. Our > deputy minister talked Yankee talk and our minister talked the Queen's > English. The same document had to be constantly translated between > English and American, depending on whose signature it was going out > under. All documents written in Treasury were collected into folders > and circulated throughout the department, starting with the Deputy > Minister, who would read them all and circle with a red pen any > translation errors, so everyone could see who had goofed. Think how > this process would have benefitted from computers! Oh, yes, computers are good for multiplying useless documents. BTW, didn't you never notice that the better office software we have, the worse documents we are producing? In case you have missed this gem: http://www.spectrum.ieee.org/may06/3447 I laughed all the way while reading it. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |