Loading ...
Sorry, an error occurred while loading the content.

Fwd: RE: Fwd: Re: [JSX] JOS problems

Expand Messages
  • Mike Goldwater
    Hi Brendan and Mark, I drafted this reply before I saw this morning s flurry of mail. ... Regards Mike ~~~~~~~~~~~~~~ Mike Goldwater Auric Hydrates Ltd 26,
    Message 1 of 1 , Jul 24, 2002
    View Source
    • 0 Attachment
      Hi Brendan and Mark,

      I drafted this reply before I saw this morning's flurry of mail.

      >Hi Brendan,
      >
      >I think that your idea No. 5 is the best contender for my application.
      >You would state a source package and then a set of possible destination
      >packages. Only the classes from the source packages would be candidates
      >for treatment. All other classes would be treated in the usual way.
      >Because this is an optional mode of operation I don't think that its
      >effect on JSX's efficiency is very important unless it involves n * n
      >searches (which it won't because you can make use of Maps). Anyway
      >efficiency is not vital in refactoring.
      >
      >Regards
      >
      >Mike
      >-----Original Message-----
      > From: "Mike Goldwater" <m_h_goldwater@...>
      > Sent: 23/07/02 21:28:53
      > To: "mike.goldwater@..." <mike.goldwater@...>
      > Subject: Fwd: Re: [JSX] JOS problems
      >
      >
      >
      >
      > >From: Mark Collette <mcollett@...>
      > >Reply-To: JSX-ideas@yahoogroups.com
      > >To: JSX-ideas@yahoogroups.com
      > >Subject: Re: [JSX] JOS problems
      > >Date: Tue, 23 Jul 2002 13:24:39 -0600
      > >
      > >I personally like idea 8 since it's the most flexible, and the
      >fastest
      > >at runtime. I think that trying to autodiscover package renaming
      >will
      > >only save the programmer 30 minutes of work at most while slowing
      >down
      > >deserialization for everyone, all the time. Remember, JSX is
      >already
      > >noticeably slower than JOS, and any more should be avoided.
      > >
      > >Mark Collette
      > >
      > >
      > >Brendan Macmillan wrote:
      > > >
      > > > Hi Mike,
      > > >
      > > > This is a long email - please skim through the introduction, up
      >until
      > > > the options numbered (1) etc begin. That introduction will
      >guide you
      > > > through the rest of the email. Good luck!
      > > >
      > > > > > > Another idea would be for an option for JSX to ignore
      >class
      > > > > > > qualifiers.
      > > > ...
      > > > > > >I would really like to re-organize my code but
      > > > > > > without some rugged recovery mechanism I do not dare.
      > > > Great idea for refactoring packages! I've now had a good
      > > > think about your suggestion, so please "reality check" my
      >solutions
      > > > below, and let's see if we can get something simple going, that
      >will
      > > > actually help you with this real problem...
      > > >
      > > > > >I think it's dangerous to ignore class qualifiers
      > > > ...
      > > > > >JSX won't know where to look for the class, without some idea
      >of the
      > > > > >package.
      > > > ...
      > > > > >Perhaps one way to go is for JSX to have an "import"
      >instruction
      > > > > >in the XML, that would be used to resolve all the classes.
      > > > I've now gone off the "import" idea, and now think it makes more
      >sense
      > > > to only modify deserialization, and for the programmer to config
      > > > the package information in Java, rather than mucking about in
      >the XML...
      > > >
      > > > > >In summary, we would need a way to specify the packages used
      >in
      > > > > >general, with some special facility for resolving name
      >collisions.
      > > > By strange coincidence, this is precisely the form of the
      >solution
      > > > that I developed in (8) below.
      > > >
      > > > > >I agree it would be nice to have some default strategy that
      >would
      > > > > >usually work - but I can't see one that wouldn't also
      >potentially
      > > > > >be very dangerous.
      > > > And I've also incorporated your idea of automating the process
      >as much
      > > > as possible, in (5), while making it much less dangerous.
      > > >
      > > > > >I think it's dangerous to ignore class qualifiers
      > > > > I had not intended to make this the default behaviour but made
      >an
      > >option
      > > > > through the Config object or similar. Any name clashes would
      >be the
      > > > > responsibility of the developer and he should expect the
      >application
      > >to
      > > > > crash.
      > > > You are right, that I could do this, and label it "use at own
      >risk!".
      > >And
      > > > I generally agree with the concept of implementing things one
      >aspect at
      > >a
      > > > time (I learn faster that way). However, I still feel very
      > >uncomfortable
      > > > about leaving dangerous tools around the place! but let me
      >explore the
      > > > idea a little....
      > > >
      > > > Your suggestion would only affect deserialization: JSX would
      >take the
      > >full
      > > > (package qualified) classname, and truncate it to ignore the
      >package,
      > > > leaving just the classname. Now comes the tricky part - how
      >will JSX
      > >know
      > > > what package to look in, to find the class?
      > > >
      > > > Following are seven suggestions: please read (5) and (8), and
      >tell me
      > > > which would suit your needs better...
      > > >
      > > > (1).
      > > > Option one is for JSX to look in *every* package (this would
      >include all
      > > > the standard libraries, and everything in the classpath). This
      >might be
      > > > slow (but hard to tell, and that's probably OK for a migration
      >tool).
      > >But
      > > > a more serious problem is that name collisions become *much*
      >more
      > >likely,
      > > > since they can collide with names in *any* package.
      > > >
      > > > (2).
      > > > Option two is for us (as the user) to specify the packages to be
      > > > considered, when we switch on the proposed
      > > > "ignore-package-qualification" mode. Now, JSX would only look
      >into
      > > > those packages. This makes it more efficient, and reduces the
      > > > likelihood of collisions. This might seem simple, but we would
      >need
      > > > to specify *every* package used - not just our application
      >packages,
      > > > but also the standard libraries. In practice, I think it would
      >take
      > > > quite a few runs before we had got them all.
      > > >
      > > > Note that this suggestion is only to do with where we look for
      > > > classes.
      > > >
      > > > (3).
      > > > A more sophisticated version of option 2 is to only ignore the
      > > > package-qualification for *application* classes. Here's the
      >trick:
      > > > we can detect packages that begin with "java." or "javax." (or a
      > > > number of other user-nominated roots, like org.* or ), and use
      >any
      > > > such package to find the class. Now, we only need to specify
      > > > application packages to JSX, and JSX only needs to search
      >through
      > > > these (thus becoming even more efficient and reducing the chance
      > > > of collision still further).
      > > >
      > > > What's really nice about this is that we can also include
      > > > the application packages that haven't changed, thus increasing
      > > > efficiency and reducing collisions again.
      > > >
      > > > I kind of like the idea of "user-nominated package roots",
      >because it
      > > > always seemed to me that that is how import statements should
      >work
      > > > (at least when they have a directory implemention) - eg that you
      >could
      > > > say "java.lang.*", and it would include "java.lang.reflect"
      >(which it
      > > > doesn't).
      > > >
      > > > (4).
      > > > Instead of specifying the packages to "not ignore", we could do
      >the
      > > > opposite, and specify the packages that we should ignore... in
      >practice,
      > > > this may often be what you want, because there are only one or
      >two
      > > > packages that have changed in this way. It also makes it safer,
      >because
      > > > you explicitly say what you want to happen.
      > > >
      > > > We would thus only list (a). the old packages and (b). the new
      >packages.
      > > >
      > > > ***(5)***.
      > > > Finally, we can list the old and new packages separately. The
      >old list
      > > > is the packages we ignore in the XML (that is, classes from the
      > > > old packages). The new list is where to look for the class
      > > > files in order to instantiate them (that is, the new packages) -
      > > > this makes JSX's job much easier, because it knows where to
      >look.
      > > > This is quite a flexible arrangement. For example, say we had
      >package
      > > > "a", and we moved a third of the classes into package "b", and a
      >third
      > > > into "c". The scheme copes with that. It will also cope with
      >renamed
      > > > package "a" into "b" (logically the same as moving all the
      >classes into
      > >"b").
      > > >
      > > > However, there is still the chance of collision - although it is
      >much
      > > > less dangerous, simply because the package-qualification is only
      > > > ignored when the user has requested it explicitly for that
      >package...
      > > >
      > > > (6).
      > > > We can have even more specific schemes, which specify which
      >packages
      > > > are mapped to which ones (but that won't cope with the first
      >example
      > > > in (5) above). We could implement this with a hashtable (a
      >map),
      > > > with the old (XML) package being the "key", and the new package
      > > > being the "value", so that JSX just needs to extract the package
      > > > qualification, look it up in the hashtable, and prepend it to
      >the
      > > > classname again.
      > > >
      > > > However, this is quite a limited refactoring, because it only
      >works
      > > > when entire packages have been renamed - not when only a few
      >classes
      > > > have been moved.
      > > >
      > > > (7).
      > > > But the most specific scheme of all is a list of exactly what
      >classes
      > > > (including the package-qualification) are mapped onto what other
      > > > class (including the package-qualification). This avoids *all*
      > > > name collisions completely - and it's even simpler to implement
      >using
      > > > a hastable, since we don't even need to separate the package and
      > > > classname.
      > > >
      > > > However, the downside is that as users, we would need to
      >explicitly
      > > > list *every* class that had been moved across packages - so when
      >a
      > > > package containing 100 classes is renamed, we need to list them
      >all
      > > > explicitly.
      > > >
      > > > (8).
      > > > Ah! So the obvious thing is to combine solutions (6) and (7) -
      > > > if individual classes have been moved between packages, you need
      > > > to specify those classes explicitly, as in (7). But if a
      >package
      > > > has been renamed, you specify the whole package as having been
      > > > moved. JSX would check the classes (specific) before the
      >packages
      > > > (general).
      > > >
      > > > The great advantage of this method is that name collisions can
      > > > be avoided altogether, and the user is given both fine grain
      >(class)
      > > > and coarse grain (package) control.
      > > >
      > > > The necessary downside is that none of this is automated beyond
      >that
      > > > - so, for example, if package "a" had a 100 classes, and 50 were
      > > > moved to "b", then we would need to specify all 50 explicitly.
      > > > In contrast, method (5) could automate this - at the risk of
      > > > collisions.
      > > >
      > > > (9).
      > > > So, the obvious thing is to combine again: (5) to automate as
      > > > much as possible, and (8) to avoid any collisions. For safety,
      >we would
      > > > want JSX to detect any possible collisions - this means that
      > > > in terms of the JSX implementation, instead of (5) stopping as
      >soon
      > > > as it found a possible class, it would keep searching to ensure
      >there
      > > > is no ambiguity. On average, this would make it twice as slow -
      >but
      > > > since we have focussed the list of classes to search, this
      >should
      > > > even be noticeable.
      > > >
      > > > An obvious efficiency is to cache the mapping that we find when
      > >searching
      > > > with the (5) technique, so that we don't need to check for
      >collisions
      > >the
      > > > second time (and subsequent times) we encounter an instance of
      >that
      > >class.
      > > >
      > > > OK! I think I've done this idea to death now! But I still like
      >the
      > >idea
      > > > of just implementing a bit of it at a time - so which would you
      >prefer
      > > > first, (5) or (8)? I guess I'm really asking what kind of
      >package
      > > > refactorings have you done, or would you expect to do (and that
      >you
      > > > would expect others to do).
      > > >
      > > > > I have started to look for XML re-factoring tools. I am
      >currently
      > >looking at
      > > > > Xalan...
      > > > Yes, XSLT. Have a look at Mark van der Kraan's post on the list
      >(from
      > >ages
      > > > ago),
      > > > which involved mapping between the JSX format, and another XML
      >format.
      > > > Actually,
      > > > I think it's quite tricky to do this programming in XSLT....
      > > >
      > > > Cheers,
      > > > Brendan
      > > >
      > > >
      > > > To unsubscribe from this group, send an email to:
      > > > JSX-ideas-unsubscribe@egroups.com
      > > >
      > > >
      > > >
      > > > Your use of Yahoo! Groups is subject to
      > >http://docs.yahoo.com/info/terms/
      >
      >
      >
      >
      > Regards
      >
      > Mike
      > ~~~~~~~~~~~~~~
      > Mike Goldwater
      > Auric Hydrates Ltd
      > 26, Sandal Road
      > New Malden
      > Surrey KT3 5AP
      > UK
      > Tel and Fax: +44 (020) 8949 0353
      > Mobile: +44 07956 359001
      >
      >
      > _________________________________________________________________
      > Chat with friends online, try MSN Messenger:
      >http://messenger.msn.com




      Regards

      Mike
      ~~~~~~~~~~~~~~
      Mike Goldwater
      Auric Hydrates Ltd
      26, Sandal Road
      New Malden
      Surrey KT3 5AP
      UK
      Tel and Fax: +44 (020) 8949 0353
      Mobile: +44 07956 359001




      _________________________________________________________________
      Chat with friends online, try MSN Messenger: http://messenger.msn.com
    Your message has been successfully submitted and would be delivered to recipients shortly.