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.