@CodeSmith

Yes, and that goes for .sfd as well .

@CodeSmith

Hey, I just realised what this Xml stuff is really all about. And its more than just library files. Excuse me if I am stating the obvious.

Anybody who uses MS tools will notice that when you start a project you have to select what kind of project you will be creating. The IDE then goes and creates all the files and in some cases objects that you will be using in the project.

For instance if its a web project you'll get an ASPX page and related web files, if its a windows project you'll get a form object/class and other related files, if its a library you'll get a class and so on.

These XML files are like the templates for the different kind of projects you'll be working on, creating all the files or stubs code that you can modify.

Of course, we only can see that you will be building a library project in this example, and there would probably be another kind of XML structure along the same lines for a legitimate project. If Hyperion have invented any other technology for instance, there would be yet another XML structure. There may be specific ones for building drivers, services and any other kinds of projects you can think of.

If that's what its for then its pretty cool. An advanced IDE in the future will simply need to modify this XML file.

Hmmm.... wait a second. You would need to modify this XML file before you start your project at the moment because you want to enter all the interface details. I guess an IDE(That functioned like my MS example) would have to be cleverer than that and outsmart it somehow. Regenerating the library and reinserting the code. Eeeek.

Hmmm. I think I am kind of on the right track but not quite.
Oh well.

_________________
Leo Nigro, CTO Commodore USA, LLC
Opinions expressed are my own and not those of C= USA.
Commodore/AMIGA "Beautiful, High-Performance, Home Computers for Creativity and Entertainment."

@salass00

Quote:

salass00 wrote: @CodeSmith Yes, and that goes for .sfd as well .

Correct, but I think I remember Rogue saying that (s)fd files had problems with extensibility (ie they work really well for the task they were designed, but it's hard to add features to the fd "language" without making it hacky). The one obvious quality of xml is that it is very easy to extend. I guess the guys at Hyperion had some trouble trying to extend the sfd syntax in a clean, future-proof way, and then they just decided to throw the whole thing out and use xml instead, since xml is as clean and future-proof as IFF, while remaining a text format (as all source code should be).

@CodeSmith

Quote:

Correct, but I think I remember Rogue saying that (s)fd files had problems with extensibility (ie they work really well for the task they were designed, but it's hard to add features to the fd "language" without making it hacky). The one obvious quality of xml is that it is very easy to extend. I guess the guys at Hyperion had some trouble trying to extend the sfd syntax in a clean, future-proof way, and then they just decided to throw the whole thing out and use xml instead, since xml is as clean and future-proof as IFF, while remaining a text format (as all source code should be).

I guess that's the reason, yes, but I think they gave up too early on the sfd files They could have simply introduced an "interface" construct, that is just group all functions belonging to the same interface in a named block qualified by the word "interface". But I think they found it easier to implement an sfd->xml translator (just hack a bit the existing sfd tool, which has to build a sort of AST internally already), rather than adding this functionality.

Rogue's reply wasn't that clear about this subject, that's why I wondered.

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford