sheets-devel

[Sheets-devel] A big Sheets idea

[Aaron P. <ap...@cm...>]

Here's an idea I've been thinking about for a while.

One problem with using sheets with other developers is that we Sheets 
developers really want to use Sheets dump files, because it's such a 
rich format -- it saves all the hierarchies of files, fragments, etc., 
puts in separators, and all sorts of neat stuff.  But other developers 
who don't use sheets just won't develop on a project at all if we use 
dump files as our official, CVS-checked-in format*.  One argument to use 
dump files anyway is that would encourage more developers to switch to 
sheets.  But that's a Microsoft-monopoly argument -- there's so many 
development environments and some programmers are so entrenched, they 
really won't want to switch.

So what if we make sheets work well without dump files?  There's a way 
to do this -- here's a couple tricks:
1) Get rid of the exports list for a class and export in the order users 
have organized their fragments.
2) Turn separators into /* 
---------------------------------------------------------- */ and parse 
them back out into separators when they come back in
3) Use comments to show where fragments go in the hierarchy of sheets -- 
at the beginning of a fragment, show a /* This Method's hierarchy: 
Project Sheets -> Util Package -> CollectionUtils -> Collection Utils 
Mouse Listener Stuff */
(I only made up the last sheet name -- otherwise it's a real hierarchy)
This makes it human-readable and I think it has all the info that's in 
Sheets dump files.
There's also a bug you mentioned with dump files that CVS and diffs 
eventually work poorly on large ones -- I dunno if you fixed that, but 
it wouldn't be a problem if something like this happened.  Of course, 
CVS merges would be harder because people can move methods around, but 
that's just where CVS starts failing, not Sheets.

I think this might be the way Sheets should evolve.  Of course, it's a 
tremendously large leap and requires a ton of changes to the code.

* Of course, sheets dump files are just fine for the Sheets repository 
where people are working on sheets
 
 - Aaron

Re: [Sheets-devel] A big Sheets idea

[Stephen C. <sj...@br...>]

Good point.  If you have noticed, I have been spending a lot of time
recently making sure sheets plays nicely with files on disk.  It now is much
more conservative about exporting (it will only export a java file if it has
been modified...  and rather than exporting to mark a file as dirty, it
simply touches the file on disk).

I really want to get started on doing some true versioning in Sheets.  This
is the ultimate goal of the project, and it will be the main differentiator
in the long run.  However, the same problem with filesystems exists for
version control systems.  Once I build a new version control system into
sheets, it needs to be compatible with CVS to be widely adopted.

I like your idea about storing meta information in the java files to
preserve a round trip import/export.  That might also be a good way to
bridge the gap between CVS and the SVS (Sheets Versioning System).

Following the principle of least astonishment, I'd like the export format to
stay roughly the same unless the user makes a change in Sheets.  For
instance, if you import stuff and leave it on the default sheet, there is no
need to export extra information in the Java file about the location of the
methods.  However, if you did a Sheets-ism like moving a few classes onto
the same Sheet, or renaming the Sheet to something more meaningful, then it
should export that information into the java file.

I forgot to mention, I finished another project this weekend.  Cassandra was
born on Friday, and came home with mommy from the hospital yesterday.  I
attached a picture of her to this e-mail.  I am taking a few weeks off to
take care for mom and baby, but it looks like I may get some quality
programming time while they are sleeping (like now).

Cheers,
--Steve

----- Original Message -----
From: "Aaron Powers" <ap...@cm...>
To: <she...@li...>
Sent: Monday, May 12, 2003 4:30 PM
Subject: [Sheets-devel] A big Sheets idea


> Here's an idea I've been thinking about for a while.
>
> One problem with using sheets with other developers is that we Sheets
> developers really want to use Sheets dump files, because it's such a
> rich format -- it saves all the hierarchies of files, fragments, etc.,
> puts in separators, and all sorts of neat stuff.  But other developers
> who don't use sheets just won't develop on a project at all if we use
> dump files as our official, CVS-checked-in format*.  One argument to use
> dump files anyway is that would encourage more developers to switch to
> sheets.  But that's a Microsoft-monopoly argument -- there's so many
> development environments and some programmers are so entrenched, they
> really won't want to switch.
>
> So what if we make sheets work well without dump files?  There's a way
> to do this -- here's a couple tricks:
> 1) Get rid of the exports list for a class and export in the order users
> have organized their fragments.
> 2) Turn separators into /*
> ---------------------------------------------------------- */ and parse
> them back out into separators when they come back in
> 3) Use comments to show where fragments go in the hierarchy of sheets --
> at the beginning of a fragment, show a /* This Method's hierarchy:
> Project Sheets -> Util Package -> CollectionUtils -> Collection Utils
> Mouse Listener Stuff */
> (I only made up the last sheet name -- otherwise it's a real hierarchy)
> This makes it human-readable and I think it has all the info that's in
> Sheets dump files.
> There's also a bug you mentioned with dump files that CVS and diffs
> eventually work poorly on large ones -- I dunno if you fixed that, but
> it wouldn't be a problem if something like this happened.  Of course,
> CVS merges would be harder because people can move methods around, but
> that's just where CVS starts failing, not Sheets.
>
> I think this might be the way Sheets should evolve.  Of course, it's a
> tremendously large leap and requires a ton of changes to the code.
>
> * Of course, sheets dump files are just fine for the Sheets repository
> where people are working on sheets
>
>  - Aaron
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Sheets-devel mailing list
> She...@li...
> https://lists.sourceforge.net/lists/listinfo/sheets-devel
>

Re: [Sheets-devel] A big Sheets idea

[Aaron P. <ap...@cm...>]

This is a multi-part message in MIME format.