At 10:24 Uhr -0800 18.01.2002, El JoPe Magnifico wrote: >On 18 Jan 2002, Randal L. Schwartz wrote: >>> (*) As a perl devotee, I understand your revulsion to forced use of >>> indentation, Randall. I'm of the same mind... but only with respect >>> to soruce code. This is not source code though, but rather essentially >>> a config file, and use of whitespace to indicate nesting makes far more >>> sense in that circumstance, IMHO. >> >> Please don't second-guess me on this. My objection has nothing to do >> with Perl. My objection has to do with sensibility. :) >> To clue you gently in the right direction, how many spaces are in a tab? >> Careful how you answer that. > >Sorry, I shouldn't have made assumptions about the origins of your >habits. Nevertheless, your concept of sensibility is subjective: > >1. I personally make more mistakes when adding markup than I do with > indentation. No, this does not hold for everyone. > >2. I have a clue on telling my text editor not to reduce multiple > blank spaces to tabs when dealing with certain files. > No, this does not hold for everyone either. > Note, YAML uses single-space as the per-level indent character, > _not_ tab, so this is less of an issue than you are insinuating. > >Whatever, we can drop the discussion now (or take it off the list), >since there's obviously zero support for the suggestion. Which is... >just fine. =)
I wouldn't say there is zero support for it. Whatever we do, I think we should try to use something that already exists. This way, we can make use of existing code, and existing tools. Why reinvent the wheel. So, it boils down to the question: which existing format to use? YAML and XML have been the only suggestions so far. I have used XML in various projects, and know my way around it. This makes it "nicer" for me. I know it's a good format and easily capable of doing what we need. _However_, also because I know XML, I know that it's certainly not a catch-all solution, there are things for which it is better suited, and things for which it is less suited. So I try to be open-minded Let me talk about something else here: in either case (or even if somebody suggests another format), this is only part of the job. The next thing is to design a specific format, making use of the container format we decide upon. This is certainly not a completly trivial thing if we want to do it right. also, we want to allow things like building multiple variants from a single package. So, we have to decide how to represent that in the file, and how to *implement* it, too. So, we could actually even try to use *both*. What I have in mind right now is this: We first make sure the package reading code is completly seperated from the code processing it. Then we can add new package reader modules at will, e.g. one based on XML, one on YAML. We also keep the old one. Introduce new extensions for the files, like .yinfo and .xinfo or whatever. The important thing is, all parse into the same data struct. Initially, the new formats would not support more features than before. but we can add support for new features gradually, and implement them in the backends. Old .info files will still keep working. So, you now shout: "ah it is bad to have multiple different formats!". Well, I am not saying we have to do it, but the point is, if somebody is interested in it, it could easily be done. Since all formats map to the same internal representation, we can in fact trivially convert each format into the other (and convert the old .info files into the new format(s)). And if we do not want to work on both, well, just develop one, but still make the code as general as suggested above. Oh, and generating .xinfo/.yinfo files should be implemented anyway, this could be used to "beautify" packages. Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
