on 4/15/00 5:37 PM, Chris Meyer <[EMAIL PROTECTED]> wrote:
> I certainly understand the importance of that issue. On the other hand
> I've found that good rewriting and a good deprecation strategy allows the
> code to move forward. An equally important issue is code maintainability
> and readability. Just quickly scanning through the code was not enough for
> me to determine what 'eval' and 'exec' did. Not to mention the fact that
> the 'build' method for layouts doesn't return a value and the 'build'
> method for screens does which is a bit inconsistent.
No offense, but eval and exec ARE documented pretty well in their respective
javadoc. Most people read that first and then look at the code. ;-) On the
other hand, I can understand why you were looking at the code first...most
cases, the javadoc documentation sucks. ;-) I'm trying REALLY hard to
provide decent javadoc in Turbine where I can.
> A good deprecation strategy is something like: leave deprecated support in
> the next major version, phase it out in the following major version. This
> gives users a chance to migrate... For instance, leave 'build' support in
> for 2.0 but plan on getting rid of it (and telling users so) in 3.0.
Right. The problem we face is that we haven't even released a 2.0 yet. So,
people are doing a lot of code against the current versions.
On top of it, these other "products" have their own development cycles and
constraints. For example, Clear Ink (where Turbine came from originally)
uses Turbine to build web applications for their clients. These applications
are huge (many many thousands of lines of code and sometimes hundreds of
screens). So, deprecating something like the build() method will set them
back quite a bit...even though it is just warnings in the compiler it looks
really bad to leave those there.
> By the way, instead of 'exec' and 'eval', method names like
> 'addScreenElementToPage' and 'buildScreenElement' seem nicer.
seem nicer, but in the end it is just a name.
> I hope you consider my messages as constructive. Turbine seems to be a
> nicely put together system and I don't mean to be overly critical and I am
> certainly aware of the issues of migrating libraries. My day job includes
> an object-oriented script language with 1600 functions that I have to
> migrate constantly -- so I'm well aware of the issues that go along with
> an external user base and I appreciate the fact that someone who is aware
> of these issues is an active developer on this project!
>
> The thing that appeals to me about open source projects is the ability to
> contribute in a constructive way to make products that I'm interested in
> work a LOT better! My comments are directed towards that end so please
> don't think that I don't appreciate the work and design that has already
> gone into Turbine. It's a cool system.
No. I totally appreciate your comments and constructive messages. Are you in
the Bay Area? I would love to meet with you and simply just chat. I'm 100%
sure that we could get a lot of this resolved quickly in person. Most of the
time intention doesn't filter through email very well.
Part of my problem right now is that it feels like you are new to the
project and have a lot of enthusiasm for helping out on things. I really
don't want to loose that, but I do want to help focus you on the things that
are more important than renaming everything such as getting a release out
the door, adding documentation, improving the support for other systems
(like Webmacro), etc... ;-)
> PageLoader and LayoutLoader do not have 'eval' methods. I'm not sure
> they're needed but I don't see why they should be any different from the
> other ones.
Ah...this was intentional on my part. A Page is the top level of the system.
In reality most applications will only use the DefaultPage...it was designed
into things more as a way to add functionality but really shouldn't be
changed unless there is some pretty extreme differences in the way that you
want to do things. Ie: flexibility. ;-)
Since Pages load Layouts there was no real good reason for a Layout to be
eval'd since the only time a Layout will be called is from a Page which is
already pretty static in that it is a DefaultPage.
> I'll study the code more. I don't see why but I also haven't looked at
> every case in the code. Since all except for PageLoader and LayoutLoader
> have a 'eval' method that is invoked by 'exec' in the default
> implementation, I was suggesting moving 'exec' into GenericLoader and
> making it invoke 'eval' in the default case... Not sure if this is the
> exact right way to go so I'll study more... Any comments?
Study it more. The only time you really want to exec is in Screens and
Navigations. eval for everything else. BTW, this naming convention was taken
from the PHP3 eval(). exec() was actually added later.
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
