Types, packages & objects : the good old naming conventions question (without religious ware)
in [ADA]
|
Prev: Attribute denoting a subprogram : no named parameter associations allowed
Next: Question on array of strings
From: Hibou57 (Yannick Duchêne) on 30 Oct 2009 21:45 On 30 oct, 19:57, "Jeffrey R. Carter" <spam.jrcarter....(a)spam.acm.org> wrote: > When you see > > Append (List => List, Element => Element); > > you don't really know what's being appended to what. Compare that to > > Append (Onto => Widget_List, Item => Next_Widget); So in some way, the difference between the not-suffixed convention and the suffixed convention, has something similar to the difference between typed and non-typed (or loosely typed) language ? You want to mean it may be more long, sometime a bit difficult, but finally better express things, just like strong typed language takes sometime more long to setup a design, but are finally give clearer and more explicit architectures. But is it an universal feature or is it because it is Ada which does not allow object name and type name to be the same (you may reply that if Ada does not allow this, this to enforce different names) I ask questions, but right now try to give my first feeling about it : typing express the logic of a domain, and if typing is not well designed, this means the domain is not well modeled. But naming deals with natural language, whose concern is not the same as formal languages. So natural languages may not provide all the vocabulary required to express all specific nuances which come with formal languages. After all (and now I'm back to the opposite way after the previous suggestion), isn't the _Type suffix, something similar to the ending "s" meaning the plural ? If natural languages were close to formal languages, there may be a suffix expressing that a thing is an instance abstraction (a type) or even a class, just like natural languages gave us the plural mark. Two ways, with both good arguments, but this may help to better understand (linguistic and things around may be good guests here).
From: Hibou57 (Yannick Duchêne) on 31 Oct 2009 01:30 A quick add-on, before I forget to write it back here - comments welcome on the assertion : A program language terms use the dictionary of natural language. The natural language has some construct like predicates, adjectives, verbs (transitive and intransitives ones), an nouns. some has one to one match with the concepts used in a program text : predicates and adjectives, verbs (of both forms). Remain nouns : they may match either object of types, just because the natural language does not make this distinction. Indeed, in every day life, we are not talking using type and class concepts (neither our ancestors does). Human being understanding of things, which is reflected in the nature of the language it use (the Human being), because it creates the language to serve to purpose of transmitting its minds, prefer to use stereotypes : it take a typical example, which is a *real* instance, and defines other instances after that typical real instance. Thus, the word « cat », which may either refer to Douda, my pet cat, or to all Cat being (if I can say it this way). So, it may be seen as un non-formal proof that the vocabulary and word derivation construct from natural languages, does not provide anything to make a clear distinction between an instance and the abstraction of any-instance-of, simply because any instance, may be subject to become a typical representation of an abstraction as soon as it is notices that it has finally some property which makes it different from others and that these properties are shared by some other. Ex. my Pet Cat, she like to beat just to play. There are others which do the same. At first sight, she is well represented by the typical representation of a cat, which is some cat (any one), but later, when you know her, you use this reference to her in another way. So, in the natural way of Human being understanding process, there is no distinction at all, between an object and a type or a class, because an object may become a type or a class at any time. Finally, the natural language the Human being has created fulfill the needs of this process, providing a set of words which can serve this purpose, that, words which means things which may be either object or types, without this distinction being made. Here comes the clash between object name and type name. Perhaps this is not a matter of weither or not some one did not choose the good word from the natural language, and more a matter of that the natural language does not provide good words for that purpose : a word which may match the expression of what a type is, may be found, but with two things important to note : this word will never express it is a type (for the reason expressed before) and this word will *necessarily* be the word which should be used as well to name an object (still for the reason introduced before). At this point, there is three possible way to do things (if you think about others, just add your own and tell about) : 1) Created fully new words dedicated to type, not coming from the natural language, as the natural language does not provide any. 2) Formally split - in a developers wide standardized way - the whole set of words from the natural language in two separate and non-mixable set : one set for restricted to objects name, one set restricted for type names. 3) Add a derivation (which is a known construct of the natural language), to mark some property on some words, just like the already given example of plural does with the s. This may be done it self in three possible way : create a mark for types, meaning I'm a type (object will be the ones without this mark), or create a mark for objects, meaning I'm an object (types will be the ones without this mark), or create a mark for both type and object, meaning I'm a type for the first one and I'm an object for the second one. Comments on these methods (if you think about others, add you own as well). About 1) : this would not be practicable... the set of words from the natural language taken long to be created, and Human being capacity to learn such a things is not unlimited (this would be nice for a machine to create and use such a create-from-the-ground-up language, but we are Human beings, not machines). About 2) : such a standard would take long, long, long, with infinite elections before being stable. And further more, we may discover that one objet-type (as with natural language its always the two things at the time) may only have a single word to refer to, and no synonym at all. Then, even providing we may be able to standardize such a split, we may end up with some object without word (or type without word), as we will have to decide if we assign this unique word to either the type names set or object names set. Then and even if it would be less work to learn it (less than with the proposition #1), this would still be a lot of work for every one to learn it, ... and be sure there will be confusion, because we will have two set of words, whose words from one set will be synonyms of the words from the other set (synonym in the natural language way, but not in the program text way). About 3) : there are in turn three way to do it. About 3.1 (a mark for types) : a lot of people already know it, so no need to explain. About 3.2 (a mark for object) : it seems it has been in use in some old methodologies (I do not know names, sorry), I used it my self in some old Pascal programs. About 3.3 (a mark for both) : just combine de two previous Some along fact about 3) : - We spend more time to read than we spend time to write. - We write more object names than we write type names (indeed, there more instance than there instance abstraction, except in libraries). This may be a suggestion to have shorter names for object (quicker to read and to write) than for types, thus this may be a suggestion to drop 3.3 and 3.2, leaving just 3.1 Remains a thing which after all this formalizations, will remain a matter of taste : the choice of the mark on the type (suffix, prefix, casing - not for ada - and anything else, things which already in use in some conventions). Is this mark very important to be standardized ? Perhaps not, as soon as it clearly appears to stand for types, it is clearly distinct (should not be erroneously seen as the part of a word - the Ada underscore may help there) and easy to write and read (just avoid exotic characters or marks, even if some may be tempted in some mathematic of linguistic dedicated character sets). Time for comments now Note : if a language makes more use of types than objects, objects should have the mark instead of types, that's obvious, while better said explicitly.
From: Hibou57 (Yannick Duchêne) on 31 Oct 2009 01:44 On 31 oct, 06:30, Hibou57 (Yannick Duchêne) <yannick_duch...(a)yahoo.fr> wrote: > [...] simply because any instance, may be subject to become > a typical representation of an abstraction as soon as it is notices > that it has finally some property which makes it different from others This make me think that the natural language is better at analysis than it is at expressing static architecture based on formalism after analysis. this is not surprising, from thousands years, we are more busy at trying to understand things, come back on a previous understanding and reworking it (this is why it is useful to be able to have a thing which is both things). The natural language is after all perhaps better at always-moving things rather than at well-elaborated-and- expected-stable things. Hey boys and girls... you know what ? I think the natural language is an untyped loosy structured language 8-| We should rework it in whooole and send a long spicy disclaimer to its author.
From: Jacob Sparre Andersen on 31 Oct 2009 02:35 tmoran(a)acm.org wrote: > Since you probably write variable names much more often in the code > than the type name, it makes sense to try to shorten them, at the > expense of slightly longer type names. Now I simply have to quote Preben Randhol: "Saving keystrokes is the job of the text editor, not the programming language." Personally I find types the most important construct in Ada. This means that I generally try to give the "best" names to types. Naming of objects and types would be easier, if we could use two separate name spaces. But maybe our code would become harder to read? Greetings, Jacob -- Warning: Dates in calendars are closer than they appear.
From: Hibou57 (Yannick Duchêne) on 31 Oct 2009 07:30
On 31 oct, 10:49, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > "the cats" This is a class, not a type So let's call classes The_Xxxs (with an ending S) But what about types ? (and instances of a type) |