On 2010-03-24, at 00:08 , Robert Goldman wrote: > On 3/23/10 Mar 23 -8:35 AM, james anderson wrote: >> good morning; >> >> On 2010-03-18, at 21:41 , Juan Jose Garcia-Ripoll wrote: >> > >> >> Contributing to this problem is that the system and component >> forms are >> not symmetrical. The intended syntax is[2], but the implementation >> is not: >> >> ? (defclass specialized-system (asdf:system) ()) >> #<STANDARD-CLASS SPECIALIZED-SYSTEM> >> ? (defclass specialized-source-file (asdf:cl-source-file) ()) >> #<STANDARD-CLASS SPECIALIZED-SOURCE-FILE> >> ? (eval '(asdf:defsystem :a-system :class specialized- >> system :components >> ((:file "a-file")))) >> #<SPECIALIZED-SYSTEM "a-system" #xEF6724E> >> ? (eval '(asdf:defsystem :a-system :class specialized- >> system :components >> ((:file "a-file" :class specialized-source-file)))) >>> Error: :CLASS is an invalid initarg to REINITIALIZE-INSTANCE for >> #<STANDARD-CLASS ASDF:CL-SOURCE-FILE>. >>> Valid initargs: #(:CONTINGENT-ON :LONG- >>> DESCRIPTION :DESCRIPTION >> :NAME :VERSION :IN-ORDER-TO :DO-FIRST :PARENT :PATHNAME :PROPERTIES). >>> While executing: CCL::CHECK-INITARGS >>> Type Command-. to abort. >> See the Restarts… menu item for further choices. >> 1 > >> >> This should be corrected, in order that - even in the absence of an >> intended extension, asdf can interpret the standard information in a >> system definition. > > Please launchpad this bug, with a list of the set of initargs that > need > to be supported. Maybe this can be fixed. > > I am willing to believe that the initargs to system should be > supported > on components to the maximum extent possible. But I don't see any > reason, a priori, that components and systems should be treated > symmetrically. Why should we believe that, of necessity, every > form of > source file should be modeled by a data structure that shares every > attribute of a system? To take an absurd case, we don't put file > extensions on systems....
please reconsider whether, that one does not now really means that the particular feature should not be treated symmetrically. i can't answer the question, as i've not considered the implications, but, given how obviously ill-considered the :class treatment is, i would first presume symmetry and exclude upon deliberation. ? what happens of one loads a system definition from a file which is not marked type "asd"? > > Actually, I'm pretty shocked by the extent that source files /already/ > share the attributes of systems. one should more often boggle ones mind. > For example, source files, as > components, have :version attributes. But surely if one wanted to > have > versions on source-files, there should be some inheritance > relationship > between the :version one specifies on a parent system and the version > specified for its components. given how little i comprehend the version's practical effects, i would not neither deny nor confirm that. > But we make no attempt to do any such > propagation. i would, however, not admit that such a practice, in itself, indicates what should or should not be done. > Nor, since the :version is a property that lives in the > system definition, and since the :version property of a component > is not > readily checkable across system boundaries, does associating versions > with components make any particular sense. is there some inherent reason, by which version-ness does not propagate upwards? for example from the files which apply given implementation conditionalization to the system from which they are built? as noted, while unaware of how people actually use it, i would not presume asymmetry. > > The :class case, I'll grant you, /does/ make sense, but I'm not > confident we should extrapolate too far from that. if one would go through each initialization argument and consider the implications of each, i would be more inclined to believe. _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
