ebob-discussion — This is a public list for all intended discussion regarding E-BOB.

[EBOB-DISCUSS] Microsoft Patent - claims Object bench as its own making

[Ed G. <ed...@vx...>]

Hi,
I don't know if this project is active or if this is the right e-mail 
but it seems microsoft have filed a patent which basicly says they made 
the object bench first and that it is theirs. If they do this then it 
surely invalidates your project and BlueJ, hopefully you can help stop 
this happening.

Patent Request link:
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=20060101406.PGNR.&OS=DN/20060101406&RS=DN/20060101406

Digg:
http://digg.com/software/Microsoft_copies_features_attempts_to_patent

Blue J news on this issue:
http://www.bluej.org/mrt/?p=21

E.Gray - BlueJ user.

[EBOB-DISCUSS] interesting thing about undo/redo

[Liam M. <lm...@wp...>]

I posted a message on the newsgroup about undo/redo support in Eclipse. 
It looks like it *might* be in for 3.1. They've got this concept of an 
'operation history', which I think would also work for the JUnit script 
recording.

I know we were already planning on holding off on undo/redo and JUnit 
script recording, but I think this seals it- don't even bother with it 
before 3.1 is released. When it *is* released, though, it looks like 
this stuff could be kind of helpful.

Here's the proposal, with a link to the feature request:
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/R3_1/undo-redo-proposal/undo-redo%20support.html

Liam

Re: [EBOB-DISCUSS] UI for "Inspect": please respond

[Liam M. <lm...@wp...>]

Comments embedded.

Gary Pollice wrote:

>[gfp] I'm curious.
>  
>
The properties view uses a table tree viewer, but instead of allowing a 
complete heirarchy, they allow just one level- any property can have a 
"category", but you can't have nested categories. So we'd have to have a 
popup for inspecting an object within the object. (We couldn't have 
replace the contents of the properties view because that would break 
with the properties view being selection based.) Also, anyone can turn 
these categories on or off so we can't expect them to be there; the 
category would have to end up being something like the name of the 
variable, and everything else would be on the same level. It also 
doesn't support images whatsoever, so I couldn't use the same images 
that Eclipse uses in the rest of the UI. It's all less than ideal.

>[gfp] I bet with a little creativity you can come up with a 16x16 image that
>would work. You can also just use what many tools put in for public (+),
>private (-), and protected (#) properties and add something for final.
>
Are you saying we could do it in ASCII? Or come up with our own smaller 
image? I actually misspoke about the image size- I just checked, and the 
TableTreeViewer is cutting off the images to a size of 10x10 pixels, 
which I don't understand at all. The icons which are the size we would 
want are 16x16. I think that being consistent with the JDT would be 
great, seeing as how they give us a whole bunch of images to use off the 
bat. I'd also want to follow 
http://www.eclipse.org/articles/Article-UI-Guidelines/Contents.html#IconSpecsOvr_VDG.

>This way, we can expand objects that are within other objects in a UI that's
>fairly consistent with Eclipse, as opposed to a pop-up "Inspect" 
>dialog which would open yet another "Inspect" dialog.
>[gfp] There's precedent for using inspect dialogs since they are very much a
>part of debugging.
>  
>
A pop-up dialog while debugging in Eclipse? Where is that?

>[gfp] It's probably fine. Now, putting on my Mr. Draco hat ... are these the
>important things that will keep you from having a working project? What's
>the first deliverable? Get that and then incrementally add. I'm really
>concerned that you're suffering from feature creep. Not that this isn't a
>good thing to do in the sense of a research project, but you do need to
>realize that there's a deadline that will be quickly coming up.
>
Actually I'm way ahead of schedule, and I'm bored. The deadline for this 
iteration is in 1 week, I could do this in two days (seeing as how I can 
reuse most of the code), and it's really all that's assigned to me this 
iteration. If we had to release it today, I'd release the existing 
tabletreeviewer from last iteration.

Liam

RE: [EBOB-DISCUSS] UI for "Inspect": please respond

[Gary P. <gpo...@co...>]

Comments embedded below.

	--Gary
 

-----Original Message-----
From: ebo...@li...
[mailto:ebo...@li...] On Behalf Of Liam
Morley
Sent: Wednesday, December 22, 2004 3:24 AM
To: ebo...@li...
Subject: [EBOB-DISCUSS] UI for "Inspect": please respond

My original idea for what to display when the user selects "inspect" was the
Properties view that comes with Eclipse. There are a few problems with this
(ask me if you're curious),
[gfp] I'm curious.

 so I switched to a TableTreeViewer. A table tree viewer is basically a
table with a tree in the far left column. Unfortunately it doesn't allow
user-specified images in the tree column. I was really hoping to display a
field's public/private/static/final properties with an image, the same image
that gets displayed in the Package Explorer or the Outline (I'm already
displaying this for methods in the right-click). I tried putting the images
in the right column (which isn't great in any case), but they are limited to
what seems to be 16x16 pixels, which is too small.
[gfp] I bet with a little creativity you can come up with a 16x16 image that
would work. You can also just use what many tools put in for public (+),
private (-), and protected (#) properties and add something for final.

I have an idea which I think is better than the above two, but seeing as how
this would be my third rewrite, I just wanted to check with the rest of you
to get your input. The Visual Editor Project uses a TreeViewer (the view is
called "Java Beans"). You can right-click on an individual variable and
select "set text", and it will rename the item right in the tree. This is
something we can do for modifying public fields. (You can also select
"rename" to get a popup, but I prefer doing it right in the tree). It allows
images, and the "search" view uses the same 27x16 images that I would use in
its tree, so I'm guessing I wouldn't have any problem with image size.
[gfp] Modifying it the way you would in the properties or Java Beans view is
fine.

This way, we can expand objects that are within other objects in a UI that's
fairly consistent with Eclipse, as opposed to a pop-up "Inspect" 
dialog which would open yet another "Inspect" dialog.
[gfp] There's precedent for using inspect dialogs since they are very much a
part of debugging.

Here's an example of the kind of table I was thinking of (where 'o' is where
the images would be):

+ objName: ObjClassType
|-- o int primitiveField = 6
|-- o Boolean wrapperField = true
|-+ o MyInterface userClassField = MyClass
| |-- o String stringField = "my string"
| |-- o String nullField = null
| |-+ o int[] arrayField = int[2]
| | |-- int[0] = 0
| | |-- int[1] = 1
| + o List listField = ArrayList

The above is pretty much what you'd see in the debug view, except that a
non-primitive Boolean object would have a node with its primitive value
underneath it unlike above.

I think we should also stick something in the properties view, but I have no
idea what to put there. Maybe variable name, object type, associated
project, and the constructor it was instantiated with (but I'm not sure why
someone would want to know that).

Does this sound alright?
[gfp] It's probably fine. Now, putting on my Mr. Draco hat ... are these the
important things that will keep you from having a working project? What's
the first deliverable? Get that and then incrementally add. I'm really
concerned that you're suffering from feature creep. Not that this isn't a
good thing to do in the sense of a research project, but you do need to
realize that there's a deadline that will be quickly coming up.

Liam



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid reviews
on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Ebob-discussion mailing list
Ebo...@li...
https://lists.sourceforge.net/lists/listinfo/ebob-discussion

[EBOB-DISCUSS] UI for "Inspect": please respond

[Liam M. <lm...@wp...>]

My original idea for what to display when the user selects "inspect" was 
the Properties view that comes with Eclipse. There are a few problems 
with this (ask me if you're curious), so I switched to a 
TableTreeViewer. A table tree viewer is basically a table with a tree in 
the far left column. Unfortunately it doesn't allow user-specified 
images in the tree column. I was really hoping to display a field's 
public/private/static/final properties with an image, the same image 
that gets displayed in the Package Explorer or the Outline (I'm already 
displaying this for methods in the right-click). I tried putting the 
images in the right column (which isn't great in any case), but they are 
limited to what seems to be 16x16 pixels, which is too small.

I have an idea which I think is better than the above two, but seeing as 
how this would be my third rewrite, I just wanted to check with the rest 
of you to get your input. The Visual Editor Project uses a TreeViewer 
(the view is called "Java Beans"). You can right-click on an individual 
variable and select "set text", and it will rename the item right in the 
tree. This is something we can do for modifying public fields. (You can 
also select "rename" to get a popup, but I prefer doing it right in the 
tree). It allows images, and the "search" view uses the same 27x16 
images that I would use in its tree, so I'm guessing I wouldn't have any 
problem with image size.

This way, we can expand objects that are within other objects in a UI 
that's fairly consistent with Eclipse, as opposed to a pop-up "Inspect" 
dialog which would open yet another "Inspect" dialog.

Here's an example of the kind of table I was thinking of (where 'o' is 
where the images would be):

+ objName: ObjClassType
|-- o int primitiveField = 6
|-- o Boolean wrapperField = true
|-+ o MyInterface userClassField = MyClass
| |-- o String stringField = "my string"
| |-- o String nullField = null
| |-+ o int[] arrayField = int[2]
| | |-- int[0] = 0
| | |-- int[1] = 1
| + o List listField = ArrayList

The above is pretty much what you'd see in the debug view, except that a 
non-primitive Boolean object would have a node with its primitive value 
underneath it unlike above.

I think we should also stick something in the properties view, but I 
have no idea what to put there. Maybe variable name, object type, 
associated project, and the constructor it was instantiated with (but 
I'm not sure why someone would want to know that).

Does this sound alright?

Liam

[EBOB-DISCUSS] release engineering link

[Liam M. <lm...@wp...>]

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/main.html 

[EBOB-DISCUSS] Rally "acceptance"

[Liam M. <lm...@wp...>]

Rally's glossary definition of 'acceptance' is "An activity whereby the 
customer accepts the validity of a software functionality as a partial 
or complete performance of a stated system behavior." Whose job is it to 
do acceptance testing, then? It seems that that kind of thing would be 
Professor Pollice's job- we do functional testing etc., Gary does 
acceptance testing to make sure we've got the same goals. Does that 
sound right, or am I thinking of something totally different? Should we 
'hire' a new 'customer'? It seems that the XP Way is to have someone 
external do the acceptance testing.

Liam

Re: [EBOB-DISCUSS] what if a constructor argument declares a thrown exception?

[Liam M. <lm...@wp...>]

Meant to send this to the list, sorry.

-------- Original Message --------
I'm confused, this works just fine (attached). My test case looks like this:

    public void testFooBah()
    {
        Foo foo2 = new Foo();
        Bah bah2 = new Bah(foo2.getIntValue());
    }

and that fails to compile due to the uncaught exception, but everything 
else is fine.

Liam


Gary Pollice wrote:

>What do you mean "everything succeeded?" This should not result in the
>creation of a new Bah because you don't have a valid argument.
>
>	--Gary 
>
>-----Original Message-----
>From: ebo...@li...
>[mailto:ebo...@li...] On Behalf Of Liam
>Morley
>Sent: Monday, December 13, 2004 3:34 PM
>To: ebo...@li...
>Subject: [EBOB-DISCUSS] what if a constructor argument declares a thrown
>exception?
>
>Let's say we have a class Foo:
>
>Class Foo {
>    int getIntValue() throws Exception {
>       return 4;
>    }
>}
>
>and a class Bah:
>
>Class Bah {
>    Bah (int i) {}
>}
>
>What if we add a Foo object to the bench "foo1", and then try to add a Bah
>object to the bench using "foo1.getIntValue()" as a parameter in the
>constructor? Java would say we need to catch that exception somewhere, but
>where?
>
>I tried this in BlueJ... Everything succeeded, and I wasn't alerted to the
>uncaught Exception. I recorded a Unit test, which succeeded; however, when I
>opened the unit test and tried to compile it, it failed.
>
>Liam
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid reviews
>on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Ebob-discussion mailing list
>Ebo...@li...
>https://lists.sourceforge.net/lists/listinfo/ebob-discussion
>
>
>
>
>
>  
>

[EBOB-DISCUSS] what if a constructor argument declares a thrown exception?

[Liam M. <lm...@wp...>]

Let's say we have a class Foo:

Class Foo {
    int getIntValue() throws Exception {
       return 4;
    }
}

and a class Bah:

Class Bah {
    Bah (int i) {}
}

What if we add a Foo object to the bench "foo1", and then try to add a 
Bah object to the bench using "foo1.getIntValue()" as a parameter in the 
constructor? Java would say we need to catch that exception somewhere, 
but where?

I tried this in BlueJ... Everything succeeded, and I wasn't alerted to 
the uncaught Exception. I recorded a Unit test, which succeeded; 
however, when I opened the unit test and tried to compile it, it failed.

Liam

Re: [EBOB-DISCUSS] Eclipse FAQ link, and innovation grants?

[<gpo...@co...>]

Thanks for the pointer. Actually, I did apply for a grant last year with the idea, but it didn't get accepted. I've put in a grant request this year for my traceability plug-in. If you two want to apply, I'd be happy to make sure that it gets my signature if you need it. I think the date has just about passed for this though, hasn't it?

If not, and you want to get it submitted, we'll probably have to spend time to get together to make sure that it goes in properly. It's an on-line submission form.

    --Gary


> I found a really helpful link for an Eclipse FAQ - it's the same FAQ 
> that's in the official Eclipse FAQ book (in The Eclipse Series, same 
> series as our books), online.
> http://www.eclipsefaq.org/chris/faq/
> 
> Also, is this the kind of thing where we should apply for an Innovation 
> Grant?
> http://www-306.ibm.com/software/info/university/products/eclipse/eig.html
> 
> 
> Liam
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Ebob-discussion mailing list
> Ebo...@li...
> https://lists.sourceforge.net/lists/listinfo/ebob-discussion

[EBOB-DISCUSS] Eclipse FAQ link, and innovation grants?

[Liam M. <lm...@wp...>]

I found a really helpful link for an Eclipse FAQ - it's the same FAQ 
that's in the official Eclipse FAQ book (in The Eclipse Series, same 
series as our books), online.
http://www.eclipsefaq.org/chris/faq/

Also, is this the kind of thing where we should apply for an Innovation 
Grant?
http://www-306.ibm.com/software/info/university/products/eclipse/eig.html


Liam

[EBOB-DISCUSS] FWD: how to instantiate objects from a string or IType?

[Morley, L. M <lm...@WP...>]

I finally got a response on a post to the Eclipse newsgroup regarding
instantiating objects using Eclipse APIs. Here it is:

---

"We have such capability through the Visual Editor project. All you need =
is
the JEM (Jave EMF Model) feature, which is separately available from the =
VE
download page. It has complete function to allow starting the remote vm,
creating objects on it through different constructors (from the IDE's =
VM),
running methods, getting results, etc.=20

It is the org.eclipse.jem.proxy plugin that would be of interest...."

---

My original post involved having an object that implemented
org.eclipse.jdt.core.IType (IType objects represent either a source type
inside a compilation unit, or a binary type inside a class file) but not
knowing what to do with it, plus this:

Eventually, I want to be able to instantiate an object of this type =
through
any number of constructors (not just the default), and perform =
operations on
this object. I understand I'll probably have to start a new JVM to do =
this
all in. Do I need to create a new ClassLoader?...

-------

Justin and I will probably end up looking into this in the morning, and
hopefully have something worth discussing on Thursday. I think this is
probably one of the most important decisions regarding design..

Liam

=20

P.S. If you're interested in how BlueJ, bluEclipse, and the scrapbook =
handle
some of these issues:

bluEclipse has a custom class loader. It does not load a new JVM. If you =
call
System.exit(0) in bluEclipse, all of Eclipse will exit. It does not =
respond
to changes in the original resource. If you change a class definition =
for a
class currently in the OB, it will neither remove the object from the =
object
bench or update the class definition.

BlueJ isn't open source, but the System.exit(0) test only wipes out the
Object Bench, and it is then reinitialized, so it's clear that BlueJ =
runs the
OB in a separate JVM. It responds to any change in an original resource =
by
removing everything from the object bench (whether it was involved with =
that
resource or not).

The scrapbook also runs everything in a separate JVM, or at least =
catches
code like System.exit() (which throws some sort of special exception, =
which I
think is new to 3.0). However, the scrapbook will take chunks of code =
and
evaluate it; the internal objects are somewhat hidden, and it seems that
scrapbooks are written for one-time evaluation whereas we want our =
objects to
last beyond their construction.

[EBOB-DISCUSS] SWT info

[Gary P. <gpo...@co...>]

FYI,

I just came across this site that might be useful to you.
http://www.cs.umanitoba.ca/%7Eeclipse/

	--Gary

----------------------------------------------------------------------------
----------------
Gary Pollice					gpo...@cs...
Professor of Practice, Computer Science		gpo...@co...
(alternate)
Worcester Polytechnic Institute			Office: 508-831-6793
100 Institute Road				Mobile: 978-798-0019
Worcester, MA 01609-2280
http://www.cs.wpi.edu/~gpollice/

[EBOB-DISCUSS] [Fwd: [ ebob-Use Cases-1071495 ] Add Object to Object Bench (Complete)]

[Liam M. <lm...@wp...>]

The formatting for the trackers on sourceforge... in a word... sucks. As 
you guys noticed with my first use case submission, the HTML is escaped, 
and as such isn't parsed. Well, they also don't convert spaces into 
 , so I'm really unsure as to how to format anything.

I vote for choosing a new method for storing use cases, as the current 
system... well, again, it sucks.

Here are two suggestions for replacements- PLEASE either vote for one of 
these or come up with an alternative suggestion (OR vote for keeping the 
SourceForge tracker).

One possible suggestion... what we did for our SoftEng project in E Term 
was to write the use cases in HTML, and then check them in to CVS. That 
way, if we made changes, we could always run a diff, and we also got 
nice formatting whenever we wanted to show the use cases to people. (How 
exactly should we be showing use cases to our 'audience'?) This would 
favor HTML coded either by hand or by a really basic editor- anything 
created in Dreamweaver or FrontPage would probably be too difficult to diff.

Another suggestion is to put them in the "Docs" section in SourceForge. 
We get the formatting (still in HTML), and it makes it MUCH easier for 
visitors to view them by visiting our site. (It also allows us to be 
much lazier by not having to take them out of CVS and put them on our 
website.) The downside of this compared to the above option is that 
diffs are harder, but we already have a system for marking changes in 
our Docs section anyway (comments at the top of the document). It really 
doesn't matter whether you edit the HTML by hand or not in this case- 
all that should be required is that it's suitable for future changes (it 
shouldn't be so obscure that you can't edit it any more).

Neither of these suggestions have features I'd like such as automatic 
feature matrix generation, assignment of ownership, etc... but then 
again, the SourceForge tracker didn't really have automatic feature 
matrix generation either, and we can easily say "Use Case X, Owned by 
Person Y" in HTML.

Here's my complete "Add Object to Object Bench" use case, in all its 
formatted glory. This is the only place you can see it at the moment.

Liam



-------- Original Message --------
Subject: 	[ ebob-Use Cases-1071495 ] Add Object to Object Bench (Complete)
Date: 	Mon, 22 Nov 2004 23:34:59 -0800
From: 	SourceForge.net <no...@so...>
To: 	no...@so...



Use Cases item #1071495, was opened at 2004-11-23 02:31
Message generated for change (Comment added) made by imotic
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=697946&aid=1071495&group_id=123169

Category: Complete
Group: None
Status: Open
Priority: 9
Submitted By: Liam Morley (imotic)
Assigned to: Liam Morley (imotic)
Summary: Add Object to Object Bench (Complete)

Initial Comment:
Create New Instance

Primary Actor: Developer

1. Developer selects Add To Object Bench Wizard from
one of the following locations:
    - A button on the object bench itself
    - The "New..." Wizard selection
    - The context menu for .java files and public Java
classes
    - Developer can drag-and-drop a public Java class
or .java file to the Object Bench
   If a .java file is selected, it is assumed that the
public class within that file is to be used.
2. Developer fills out the name for the instance, and
selects a class from the workbench.
3. System validates the name and class (while the
Developer types) to make sure that:
    - The name is a legal java variable identifier
    - The name hasn't already been selected by an
object currently on the Bench
    - The class is either in the classpath or on the
workbench

   EXTENSIONS:
    3a. The only constructor for this class is a
default no-argument constructor:
        .1 System displays only the "Finish" action as
enabled, and notifies Developer that this is the case.
        .2 Developer selects "Finish" and advances to
step 9.
    3b. There is no default no-argument constructor
available for this class:
        .1 System displays only the "Next" action as
enabled.
        .2 Developer selects "Next" and advances to step 4.
    3c. There is both a no-argument constructor as well
as one other constructor available for this class:
        .1 System displays both "Next" and "Finish" as
enabled.
        .2 Developer selects either "Next" or "Finish"
and advances to either step 4 or step 9, respectively.

4. Developer selects "Next".
5. Developer selects a constructor.
6. System displays a list of arguments.
7. Developer specifies the parameters. Parameters can
be specified either as literals, in-place objects, or
references to objects currently on the Object Bench
(referenced by name).
8. Developer selects "Finish".
9. System creates the object using the supplied
constructor and arguments and adds it to the Object
Bench. If the Object Bench view is not already visible,
the System makes it visible.

   EXTENSIONS:
    9a. The System has an unrecoverable error that
prevents an object from being constructed from this class:
        .1 System displays message indicating this, and
presents "Cancel" action.
        .2 Developer cancels wizard.
    9b. The System has an error which prevents an
object from being constructed using the supplied arguments:
        .1 System displays message indicating this, and
presents both "Cancel" and "Back" options.
           9b1a. Developer cancels wizard.
           9b2a. Developer selects "Back" and returns
to step 6.
    9c. The System has an error which prevents an
object from being constructed using the supplied
constructor:
        .1 System displays message indicating this, and
presents both "Cancel" and "Back" options.
           9c1a. Developer cancels wizard.
           9c2a. Developer selects "Back" and returns
to step 5; the previously chosen constructor is removed
from the list of possibilities.


----------------------------------------------------------------------

>Comment By: Liam Morley (imotic)
Date: 2004-11-23 02:34

Message:
Logged In: YES 
user_id=150393

OPEN ISSUES:
1. Currently, any class from the workbench (meaning, any
class from any open java project) or the classpath can be
added to the Object Bench. This could be a potential
problem, as two classes with the same fully qualified name
can exist in separate projects. (A real world example is
having two different branches of the same source code
checked out into two separate projects.) It currently hasn't
been decided as to how this will be dealt with, or where the
responsibilities lie. This may be changed later.
2. It's currently uncertain whether or not objects will be
represented by Eclipse's internal type structure (see: IType
in the JDT Javadoc). There are potential issues concerning
the changing of the class definition of an object that is
currently attached to the Object Bench. More research is
necessary.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=697946&aid=1071495&group_id=123169

[EBOB-DISCUSS] test driven development of UI article

[Liam M. <lm...@wp...>]

"What is preventing people from building GUIs in an Agile way? Whether
their application is web-based or a desktop application, most developers
don't do test-driven development (TDD) of the user interface. This is for
a simple reason: unit testing GUI software is hard." This is the problem
that Paul Hamill, author of Unit Test Frameworks sets out to fix in Agile
User Interface Development. By splitting his GUI elements into "smart
objects" and "thin views," he maximizes the functionality that can be
exposed to testing.


http://www.onjava.com/pub/a/onjava/2004/11/17/agileuser_1.html

I haven't read the article yet, but this might be something we might 
want to think about.

Liam

Re: [EBOB-DISCUSS] coding style

[Liam M. <lm...@wp...>]

I was thinking about that. I was curious what happens when I've got 
preferences for different plug-ins, though? I actually just tried 
exporting it to see what's in it... it looks like the things we'd be 
most concerned with, code formatting and code templates, aren't in the 
epf file, so if we wanted to we could just export those two as xml 
files. I attached the code templates (and organize imports) settings -- 
you'll want to change the template for Comments>Types, it has my email 
address -- but I figured it'd be best if we stick with the built-in Java 
Conventions for formatting. Oh, and code formatting doesn't actually run 
unless you choose to run it, so either press CTRL+SHIFT+F or select 
Source>Format from the Eclipse menu before checking things in.

btw, I forgot to mention a great plugin the other day- JadClipse. It's a 
great plugin that uses the Jad Decompiler to open class files within 
eclipse. You have to download Jad separately, I personally use DJ Java 
Decompiler which includes it. You can get that at 
http://dj.navexpress.com/djdec377.zip (if that doesn't work, do an I 
Feel Lucky on DJ Java Decompiler, but the Russian alternative download 
sites never work for me- don't worry, the program's pretty reputable and 
works great- but it will try to associate itself with both .class files 
and .java files within Windows, so make sure you uncheck that in the 
setup if you don't want to). You can get the jadclipse plugin from 
http://sourceforge.net/projects/jadclipse/

Liam


Gary Pollice wrote:

>Well, a simple thing is to make your environment preferences have the style
>you want, then export them to a .epf file. Then put it in the project for
>other people to import into their eclipse workspace for the project.
>
>	--Gary 
>
>-----Original Message-----
>From: ebo...@li...
>[mailto:ebo...@li...] On Behalf Of Liam
>Morley
>Sent: Saturday, November 13, 2004 3:16 AM
>To: ebo...@li...
>Subject: [EBOB-DISCUSS] coding style
>
>Looking at the Prop-Ed wiki page reminded me of something... coding style.
>It's probably good to be consistent. I suggest using the Java Built-in
>style, as far as code formatting goes. I'm sure other issues will come up..
>I'd like to see a document get added to the Docs page on SF. Here are a few
>ideas, some of which are copied/pasted from Kevin's coding guidelines page
>(some of which I have a different opinion on)... 
>some of them are really basic and common sense, others are good habits i've
>been taught, still others boil down to personal opinion. If all of this
>sounds good, then great- if some of this sounds bad or if there's something
>missing, then reply. If you don't think there needs to be a official
>document that decrees our coding style, that's cool too.
>
>
>
>Eclipse has a lot of default code templates that mention something like "To
>change this, please go to Window > Preferences > Java > Code Style > Code
>Templates". I can't remember what they say exactly because I already got rid
>of that part... I think one of the files I checked in still has it. We
>should probably remove that from our code templates.
>
>I'll have to check whether or not the Eclipse license needs to be included
>with the sourcecode... a lot of people throw the license (or a disclaimer,
>which is scary) at the top of each source file. That'd be easy if we wanted
>to do that, or if we wanted to have something else.
>
>*Meaningful* javadoc is important. The question is, what gets javadoc? 
>Public only methods/fields? or private methods too? What about private
>fields?
>
>I'd say we can probably safely settle on java 1.4 as a target jvm to shoot
>for; we can probably avoid using new java 1.5 code.
>
>As far as code suggestions go:
>If possible, use an interface as a return type rather than the class that
>actually implements the interface. What I mean by this is, let's say your
>method returns an ArrayList. If possible, you want to return a Collection
>object instead, or if you need to return specific list functionality then
>return the List. No casting is necessary, just specify "Collection" or
>"List" as the return type and you're set.
>
>As far as using arrays vs. the Collection heirarchy goes... I always thought
>it's best to use arrays when dealing with data that has a fixed count, and
>collections when dealing with things that change size. Some people say to
>always use Collection, but I think that there's some unnecessary overhead.
>Arrays are often more concise/readable when it comes to for loops etc (that
>is, before java 1.5).
>
>If you're using a Collection and you're not sure which implementation to go
>with, when in doubt, use ArrayList. It's faster.
>
>When accessing a Collection that implements the "java.util.RandomAccess" 
>interface (like ArrayList, Stack, or Vector),  use this:
>
>for (int i=0, n=list.size(); i < n; i++)
>         list.get(i);
>
>instead of this:
>
>for (Iterator i=list.iterator(); i.hasNext(); )
>         i.next();
>
>It's faster. (The javadoc page for RandomAccess explains it better.)
>Consequently when using something that doesn't implement RandomAccess, use
>an iterator. (Or if you need to traverse a list in either direction or
>add/remove from a list while traversing it, use ListIterator, but only if
>you have to.)
>
>Some people say to return Iterators instead of Collections. I prefer to
>return collections (rendered unmodifiable using the Collections utility
>class if this makes sense) because you can only use an Iterator once, and it
>doesn't support random access.
>
>Use the final modifier when possible.
>
>Try not to use the ?: ternary operator, unless it makes MORE sense than
>using if/else and it's really brief.
>
>When choosing between code conciseness and clarity, go for clarity.
>
>Use common sense when it comes to using braces on one-line statements. 
>If the statement's easier to read without the clutter, leave it out; if it's
>easier to read with the structure, leave it in.
>
>Last but not least, don't break the build.;) Comments?
>
>Liam
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD -
>A multidimensional database that combines robust object and relational
>technologies, making it a perfect match for Java, C++,COM, XML, ODBC and
>JDBC. www.intersystems.com/match8
>_______________________________________________
>Ebob-discussion mailing list
>Ebo...@li...
>https://lists.sourceforge.net/lists/listinfo/ebob-discussion
>
>
>
>
>  
>

RE: [EBOB-DISCUSS] coding style

[Gary P. <gpo...@co...>]

Well, a simple thing is to make your environment preferences have the style
you want, then export them to a .epf file. Then put it in the project for
other people to import into their eclipse workspace for the project.

	--Gary 

-----Original Message-----
From: ebo...@li...
[mailto:ebo...@li...] On Behalf Of Liam
Morley
Sent: Saturday, November 13, 2004 3:16 AM
To: ebo...@li...
Subject: [EBOB-DISCUSS] coding style

Looking at the Prop-Ed wiki page reminded me of something... coding style.
It's probably good to be consistent. I suggest using the Java Built-in
style, as far as code formatting goes. I'm sure other issues will come up..
I'd like to see a document get added to the Docs page on SF. Here are a few
ideas, some of which are copied/pasted from Kevin's coding guidelines page
(some of which I have a different opinion on)... 
some of them are really basic and common sense, others are good habits i've
been taught, still others boil down to personal opinion. If all of this
sounds good, then great- if some of this sounds bad or if there's something
missing, then reply. If you don't think there needs to be a official
document that decrees our coding style, that's cool too.



Eclipse has a lot of default code templates that mention something like "To
change this, please go to Window > Preferences > Java > Code Style > Code
Templates". I can't remember what they say exactly because I already got rid
of that part... I think one of the files I checked in still has it. We
should probably remove that from our code templates.

I'll have to check whether or not the Eclipse license needs to be included
with the sourcecode... a lot of people throw the license (or a disclaimer,
which is scary) at the top of each source file. That'd be easy if we wanted
to do that, or if we wanted to have something else.

*Meaningful* javadoc is important. The question is, what gets javadoc? 
Public only methods/fields? or private methods too? What about private
fields?

I'd say we can probably safely settle on java 1.4 as a target jvm to shoot
for; we can probably avoid using new java 1.5 code.

As far as code suggestions go:
If possible, use an interface as a return type rather than the class that
actually implements the interface. What I mean by this is, let's say your
method returns an ArrayList. If possible, you want to return a Collection
object instead, or if you need to return specific list functionality then
return the List. No casting is necessary, just specify "Collection" or
"List" as the return type and you're set.

As far as using arrays vs. the Collection heirarchy goes... I always thought
it's best to use arrays when dealing with data that has a fixed count, and
collections when dealing with things that change size. Some people say to
always use Collection, but I think that there's some unnecessary overhead.
Arrays are often more concise/readable when it comes to for loops etc (that
is, before java 1.5).

If you're using a Collection and you're not sure which implementation to go
with, when in doubt, use ArrayList. It's faster.

When accessing a Collection that implements the "java.util.RandomAccess" 
interface (like ArrayList, Stack, or Vector),  use this:

for (int i=0, n=list.size(); i < n; i++)
         list.get(i);

instead of this:

for (Iterator i=list.iterator(); i.hasNext(); )
         i.next();

It's faster. (The javadoc page for RandomAccess explains it better.)
Consequently when using something that doesn't implement RandomAccess, use
an iterator. (Or if you need to traverse a list in either direction or
add/remove from a list while traversing it, use ListIterator, but only if
you have to.)

Some people say to return Iterators instead of Collections. I prefer to
return collections (rendered unmodifiable using the Collections utility
class if this makes sense) because you can only use an Iterator once, and it
doesn't support random access.

Use the final modifier when possible.

Try not to use the ?: ternary operator, unless it makes MORE sense than
using if/else and it's really brief.

When choosing between code conciseness and clarity, go for clarity.

Use common sense when it comes to using braces on one-line statements. 
If the statement's easier to read without the clutter, leave it out; if it's
easier to read with the structure, leave it in.

Last but not least, don't break the build.;) Comments?

Liam



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD -
A multidimensional database that combines robust object and relational
technologies, making it a perfect match for Java, C++,COM, XML, ODBC and
JDBC. www.intersystems.com/match8
_______________________________________________
Ebob-discussion mailing list
Ebo...@li...
https://lists.sourceforge.net/lists/listinfo/ebob-discussion

[EBOB-DISCUSS] coding style

[Liam M. <lm...@wp...>]

Looking at the Prop-Ed wiki page reminded me of something... coding 
style. It's probably good to be consistent. I suggest using the Java 
Built-in style, as far as code formatting goes. I'm sure other issues 
will come up.. I'd like to see a document get added to the Docs page on 
SF. Here are a few ideas, some of which are copied/pasted from Kevin's 
coding guidelines page (some of which I have a different opinion on)... 
some of them are really basic and common sense, others are good habits 
i've been taught, still others boil down to personal opinion. If all of 
this sounds good, then great- if some of this sounds bad or if there's 
something missing, then reply. If you don't think there needs to be a 
official document that decrees our coding style, that's cool too.



Eclipse has a lot of default code templates that mention something like 
"To change this, please go to Window > Preferences > Java > Code Style > 
Code Templates". I can't remember what they say exactly because I 
already got rid of that part... I think one of the files I checked in 
still has it. We should probably remove that from our code templates.

I'll have to check whether or not the Eclipse license needs to be 
included with the sourcecode... a lot of people throw the license (or a 
disclaimer, which is scary) at the top of each source file. That'd be 
easy if we wanted to do that, or if we wanted to have something else.

*Meaningful* javadoc is important. The question is, what gets javadoc? 
Public only methods/fields? or private methods too? What about private 
fields?

I'd say we can probably safely settle on java 1.4 as a target jvm to 
shoot for; we can probably avoid using new java 1.5 code.

As far as code suggestions go:
If possible, use an interface as a return type rather than the class 
that actually implements the interface. What I mean by this is, let's 
say your method returns an ArrayList. If possible, you want to return a 
Collection object instead, or if you need to return specific list 
functionality then return the List. No casting is necessary, just 
specify "Collection" or "List" as the return type and you're set.

As far as using arrays vs. the Collection heirarchy goes... I always 
thought it's best to use arrays when dealing with data that has a fixed 
count, and collections when dealing with things that change size. Some 
people say to always use Collection, but I think that there's some 
unnecessary overhead. Arrays are often more concise/readable when it 
comes to for loops etc (that is, before java 1.5).

If you're using a Collection and you're not sure which implementation to 
go with, when in doubt, use ArrayList. It's faster.

When accessing a Collection that implements the "java.util.RandomAccess" 
interface (like ArrayList, Stack, or Vector),  use this:

for (int i=0, n=list.size(); i < n; i++)
         list.get(i);

instead of this:

for (Iterator i=list.iterator(); i.hasNext(); )
         i.next();

It's faster. (The javadoc page for RandomAccess explains it better.) 
Consequently when using something that doesn't implement RandomAccess, 
use an iterator. (Or if you need to traverse a list in either direction 
or add/remove from a list while traversing it, use ListIterator, but 
only if you have to.)

Some people say to return Iterators instead of Collections. I prefer to 
return collections (rendered unmodifiable using the Collections utility 
class if this makes sense) because you can only use an Iterator once, 
and it doesn't support random access.

Use the final modifier when possible.

Try not to use the ?: ternary operator, unless it makes MORE sense than 
using if/else and it's really brief.

When choosing between code conciseness and clarity, go for clarity.

Use common sense when it comes to using braces on one-line statements. 
If the statement's easier to read without the clutter, leave it out; if 
it's easier to read with the structure, leave it in.

Last but not least, don't break the build.;) Comments?

Liam

[EBOB-DISCUSS] found swt.graphics; it's a trade-off

[Liam M. <lm...@WP...>]

After looking through a few more SWT docs, I found a package I must have 
overlooked before -- org.eclipse.swt.graphics -- that handles drawing 
simple shapes. There's a class called GC that can draw rectangles, 
gradient rectangles, rounded rectangles, etc. However, it looks like it 
might be more difficult to use than GEF (though not impossible).

The key part of the existing code base, where all of this fits in, is 
ObjBenchView.createPartControl(Composite). This is the entry point to 
the view, where we get a reference to a "Composite" object, which as far 
as I can tell is more or less like a JComponent object, as far as its 
place in the heirarchy goes.

I've been looking into GEF the last few days (as you know), and it has a 
nice component-oriented system. You create a "Figure" (which is the 
parent class for different types of shapes, including RoundedRectangle) 
and add it to a FigureCanvas; the FigureCanvas is a go-between between 
the SWT Composite object and the GEF Figure objects. This makes it 
really easy to add/remove things; all you need to do is add these 
RoundedRectangles to the parent, and the layout manager handles their 
placement.

SWT's drawing is a little more like the AWT. You create a new GC object, 
using the passed-in Composite object's Display:
GC gc = new GC(parent.getDisplay());

Then you just call draw methods on the GC object, like this:
gc.drawRoundRectangle(int x, int y, int width, int height, int arcWidth, 
int arcHeight);

This is a little more difficult to deal with. Now the view is not only 
responsible for adding and removing, but for doing the drawing as well.. 
unless we go passing the gc object to the component to be added, in 
which case the component needs to be concerned about its placement. What 
happens if we remove the 2nd component out of 5? We'll have to worry 
about redrawing the other 3. As this is more low-level, it will be 
harder to code well, or rather we'll have to do more.

So there's a trade-off; do we stick with GEF, that makes everything 
easier, or do we write something around SWT, so that we don't force 
users to include extra plug-ins?

[EBOB-DISCUSS] Re: [EBOB-DISCUSSION] organizational questions

[Liam M. <lm...@WP...>]

Right, just for debugging. We might not really need the Log4E plug-in in 
any case, a pretty simple logger class is included in Quality Eclipse 
book... I was just throwing it out there.

Liam

Gary Pollice wrote:

>So, why do you need logging? Is it for tracking down problems? 
>
>-----Original Message-----
>From: ebo...@li...
>[mailto:ebo...@li...] On Behalf Of Liam
>Morley
>Sent: Thursday, November 11, 2004 4:07 PM
>To: ebo...@li...
>Subject: [EBOB-DISCUSSION] organizational questions
>
>As far as organization and environment is concerned- do we want to settle on
>Eclipse 3.0? I vote yes.
>
>Other *suggestions* that are completely and totally open for discussion:
>
>Eclipse Plug-ins that I use (and maybe you should too?):
>
>    * GEF SDK 3.0.1 (can be downloaded through Help>
>    * JDocSearch 0.0.3 http://www.jdocs.com/plugins/eclipse/index.html
>      (for searching through Open Source APIs)
>    * Log4E 0.7.6 http://log4e.jayefem.de/index.php/Main_Page (haven't
>      really investigated this, but it's designed to make logging easier)
>    * Any others?
>
>Use Cases
>http://sourceforge.net/tracker/?atid=697946&group_id=123169&func=browse
>I've just recently created a new tracker at SourceForge for use cases. I
>didn't know you could create your own trackers until now.. we could create
>new trackers for other things (like user stories) if we wanted to. As it is,
>we can connect features to use cases and vice versa. 
>Unfortunately this is one-way linking- we can tell that use case UC1
>addresses feature F1, but we'd also need to edit F1 to say that it's
>addressed by UC1. (Instead of being called F1, SF gives everything unique
>numbers.)
>
>Features
>http://sourceforge.net/tracker/?atid=695629&group_id=123169&func=browse
>I've updated the features list on here, it's more or less up-to-date. If I'm
>missing anything, feel free to add it.
>
>Bugs http://sourceforge.net/tracker/?atid=695626&group_id=123169&func=browse
>
>Discussion:
>mailing lists:
>
>    * General discussion ebo...@li... (all
>      three of us, open list)
>    * Development discussion ebo...@li... (just
>      Justin and I)
>
>It seems weird to have a mailing list with just two people- the reason I
>made it was because the list gets archived. This will help if we ever need
>to go back and talk about a decision we made months prior over email.
>
>Developer Documentation:
>http://sourceforge.net/docman/?group_id=123169 Our vision is already here.
>We might want to discuss what documents we feel are necessary to write; do
>we need a software architecture document, etc., or will use cases (which
>already have a tracker) be sufficient?
>
>User Documentation:
>We could keep some user documentation in the same place (under a different
>category) if necessary, but generally we should be able to keep everything
>within the Eclipse Help system.
>
>What's left (discussion points)?
>A calendar to keep track of iterations and help plan? Should the Dashboard
>software be used as a group, or should we use it on a more individual level?
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's
>Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>Ebob-discussion mailing list
>Ebo...@li...
>https://lists.sourceforge.net/lists/listinfo/ebob-discussion
>
>
>
>
>  
>

[EBOB-DISCUSS] RE: [EBOB-DISCUSSION] organizational questions

[Gary P. <gpo...@co...>]

So, why do you need logging? Is it for tracking down problems? 

-----Original Message-----
From: ebo...@li...
[mailto:ebo...@li...] On Behalf Of Liam
Morley
Sent: Thursday, November 11, 2004 4:07 PM
To: ebo...@li...
Subject: [EBOB-DISCUSSION] organizational questions

As far as organization and environment is concerned- do we want to settle on
Eclipse 3.0? I vote yes.

Other *suggestions* that are completely and totally open for discussion:

Eclipse Plug-ins that I use (and maybe you should too?):

    * GEF SDK 3.0.1 (can be downloaded through Help>
    * JDocSearch 0.0.3 http://www.jdocs.com/plugins/eclipse/index.html
      (for searching through Open Source APIs)
    * Log4E 0.7.6 http://log4e.jayefem.de/index.php/Main_Page (haven't
      really investigated this, but it's designed to make logging easier)
    * Any others?

Use Cases
http://sourceforge.net/tracker/?atid=697946&group_id=123169&func=browse
I've just recently created a new tracker at SourceForge for use cases. I
didn't know you could create your own trackers until now.. we could create
new trackers for other things (like user stories) if we wanted to. As it is,
we can connect features to use cases and vice versa. 
Unfortunately this is one-way linking- we can tell that use case UC1
addresses feature F1, but we'd also need to edit F1 to say that it's
addressed by UC1. (Instead of being called F1, SF gives everything unique
numbers.)

Features
http://sourceforge.net/tracker/?atid=695629&group_id=123169&func=browse
I've updated the features list on here, it's more or less up-to-date. If I'm
missing anything, feel free to add it.

Bugs http://sourceforge.net/tracker/?atid=695626&group_id=123169&func=browse

Discussion:
mailing lists:

    * General discussion ebo...@li... (all
      three of us, open list)
    * Development discussion ebo...@li... (just
      Justin and I)

It seems weird to have a mailing list with just two people- the reason I
made it was because the list gets archived. This will help if we ever need
to go back and talk about a decision we made months prior over email.

Developer Documentation:
http://sourceforge.net/docman/?group_id=123169 Our vision is already here.
We might want to discuss what documents we feel are necessary to write; do
we need a software architecture document, etc., or will use cases (which
already have a tracker) be sufficient?

User Documentation:
We could keep some user documentation in the same place (under a different
category) if necessary, but generally we should be able to keep everything
within the Eclipse Help system.

What's left (discussion points)?
A calendar to keep track of iterations and help plan? Should the Dashboard
software be used as a group, or should we use it on a more individual level?



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's
Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Ebob-discussion mailing list
Ebo...@li...
https://lists.sourceforge.net/lists/listinfo/ebob-discussion

[EBOB-DISCUSSION] organizational questions

[Liam M. <lm...@WP...>]

As far as organization and environment is concerned- do we want to 
settle on Eclipse 3.0? I vote yes.

Other *suggestions* that are completely and totally open for discussion:

Eclipse Plug-ins that I use (and maybe you should too?):

    * GEF SDK 3.0.1 (can be downloaded through Help>
    * JDocSearch 0.0.3 http://www.jdocs.com/plugins/eclipse/index.html
      (for searching through Open Source APIs)
    * Log4E 0.7.6 http://log4e.jayefem.de/index.php/Main_Page (haven't
      really investigated this, but it's designed to make logging easier)
    * Any others?

Use Cases 
http://sourceforge.net/tracker/?atid=697946&group_id=123169&func=browse
I've just recently created a new tracker at SourceForge for use cases. I 
didn't know you could create your own trackers until now.. we could 
create new trackers for other things (like user stories) if we wanted 
to. As it is, we can connect features to use cases and vice versa. 
Unfortunately this is one-way linking- we can tell that use case UC1 
addresses feature F1, but we'd also need to edit F1 to say that it's 
addressed by UC1. (Instead of being called F1, SF gives everything 
unique numbers.)

Features 
http://sourceforge.net/tracker/?atid=695629&group_id=123169&func=browse
I've updated the features list on here, it's more or less up-to-date. If 
I'm missing anything, feel free to add it.

Bugs http://sourceforge.net/tracker/?atid=695626&group_id=123169&func=browse

Discussion:
mailing lists:

    * General discussion ebo...@li... (all
      three of us, open list)
    * Development discussion ebo...@li... (just
      Justin and I)

It seems weird to have a mailing list with just two people- the reason I 
made it was because the list gets archived. This will help if we ever 
need to go back and talk about a decision we made months prior over email.

Developer Documentation:
http://sourceforge.net/docman/?group_id=123169 Our vision is already 
here. We might want to discuss what documents we feel are necessary to 
write; do we need a software architecture document, etc., or will use 
cases (which already have a tracker) be sufficient?

User Documentation:
We could keep some user documentation in the same place (under a 
different category) if necessary, but generally we should be able to 
keep everything within the Eclipse Help system.

What's left (discussion points)?
A calendar to keep track of iterations and help plan? Should the 
Dashboard software be used as a group, or should we use it on a more 
individual level?