RE: [9fans] source code as data not text

["Richard Elberger" <richelbe@richelberger.com>]

In my opinion, you're on the right track.

As for databases storing code, I think it is good.  I disagree with Laura's
shell script (etc) theory -- I have a hard time believing she works in
anything else but an academic environment -- I have been doing release
management for a long time and I would rather have code stored in a
clustered rdbms that is accessed through its own shell [that is
cross-platform like limbo] than relying on shell scripts, etc, that aren't
cross-platform.  In fact, you'd be surprised how many big software companies
are already moving that way with internal teams building such change
management systems.

2p.

-- rich

>-----Original Message-----
>From: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu]On Behalf
>Of Matt
>Sent: Monday, 18 June 2001 9:14 p.m.
>To: 9fans@cse.psu.edu
>Subject: Re: [9fans] source code as data not text
>
>
>bah, my fault but I wasn't really thinking about the database side of
>things. Changing the file format is definately a no-no.
>
>What sparked my interest was making the editor do more work.
>Maybe it's because I write code that writes code and having string literals
>in a different colour from the source code helps me see.
>
>I did like VB's auto parsing if input code. Highlighting a
>sections that are
>stynax errors etc. must reduce the cycle?
>
>I'm glad I asked here though. Can't think of a better bunch of
>people to run
>it past.
>
>matt
>
>
>
>
>
>