Page Comparison

[00:55:16 EDT(-0400)] * deuce (n=deuce@ip70-162-119-62.ph.ph.cox.net) has joined ##uportal
[07:34:58 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-204-94-59.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[08:34:53 EDT(-0400)] * esm (n=esm@clue.mse.jhu.edu) has joined ##uportal
[08:59:53 EDT(-0400)] <EricDalquist> yay snow!
[08:59:54 EDT(-0400)] <EricDalquist>
[09:01:20 EDT(-0400)] <esm> oh man
[09:01:26 EDT(-0400)] <esm> its cold here, but not snowing.
[09:01:49 EDT(-0400)] <EricDalquist> we got ~ 6 inches last night
[09:01:59 EDT(-0400)] <EricDalquist> and it is still coming down
[09:02:26 EDT(-0400)] <esm> well, I hope you are staying home from work today in celebration
[09:02:30 EDT(-0400)] <EricDalquist> yeah
[09:02:37 EDT(-0400)] <EricDalquist> Gretchen got a snow day today
[09:02:50 EDT(-0400)] <esm> Nice.
[09:02:51 EDT(-0400)] <EricDalquist> and the buses always get iffy when we get unexpected snow
[09:02:59 EDT(-0400)] <esm> never get snow days.
[09:03:01 EDT(-0400)] <EricDalquist> so today is a sit on the couch and hack at object ids
[09:03:17 EDT(-0400)] <esm> if our president can get to work, everyone works.
[09:03:22 EDT(-0400)] <EricDalquist> nice
[09:03:23 EDT(-0400)] <esm> and the president lives on campus
[09:03:29 EDT(-0400)] <esm> thats the joke anyway
[09:03:29 EDT(-0400)] <EricDalquist> I was just going to ask
[09:03:47 EDT(-0400)] <EricDalquist>
[09:06:04 EDT(-0400)] <EricDalquist> the javadoc for Class.isAssignableFrom is terrible
[09:06:20 EDT(-0400)] <esm> LOL
[09:06:21 EDT(-0400)] <esm> yes
[09:06:43 EDT(-0400)] <EricDalquist> I can never remember which direction to do the check
[09:07:39 EDT(-0400)] <esm> well, it has the word "Class" in it too many times
[09:07:41 EDT(-0400)] <esm> that is for sure
[09:07:54 EDT(-0400)] <EricDalquist> yup
[09:12:01 EDT(-0400)] <esm> I don't know what an "identity conversion" is.
[09:12:16 EDT(-0400)] <esm> Object foo = new Foo();
[09:12:20 EDT(-0400)] <EricDalquist> I thnk so
[09:12:20 EDT(-0400)] <esm> Object bar = new Bar();
[09:12:30 EDT(-0400)] <esm> foo = bar;
[09:12:33 EDT(-0400)] <EricDalquist> anything going 'up' the inheretence tree
[09:12:50 EDT(-0400)] <EricDalquist> so there isn't a need for a cast check
[09:12:51 EDT(-0400)] <esm> thats what i thougth a "widening reference conversion" was
[09:12:56 EDT(-0400)] <EricDalquist> oh
[09:12:57 EDT(-0400)] <EricDalquist> hrm
[09:13:00 EDT(-0400)] <esm> heh anyway
[09:13:09 EDT(-0400)] <EricDalquist>
[11:05:25 EDT(-0400)] <EricDalquist> oi there appears to be whole chunks of code that just isn't used
[11:09:53 EDT(-0400)] <esm> uh-huh
[11:10:00 EDT(-0400)] <esm> what in particular did you notice
[11:10:03 EDT(-0400)] <EricDalquist> I'm going through the id stuff
[11:10:09 EDT(-0400)] <EricDalquist> and I found an INodeId
[11:10:11 EDT(-0400)] <esm> yup
[11:10:16 EDT(-0400)] <EricDalquist> which doesn't appear to have any actual impl
[11:10:28 EDT(-0400)] <EricDalquist> and it doesn't look like it or the other classes in that package are used
[11:11:40 EDT(-0400)] <esm> I removed INodeId in the refactor branch
[11:12:15 EDT(-0400)] <esm> and noticed that the package seemed to be unused. but not knowing the code well, and considering the task at hand, I just deleted INodeId
[11:12:24 EDT(-0400)] <EricDalquist> and all the classes that use it?
[11:12:26 EDT(-0400)] <esm> er maybe i just deleted the factory
[11:12:29 EDT(-0400)] <EricDalquist> ah
[11:12:36 EDT(-0400)] <EricDalquist> yeah probably just the factory
[11:12:37 EDT(-0400)] <esm> sorry my grep skills failed me
[11:12:46 EDT(-0400)] <esm> yeah I just removed the factory
[11:12:54 EDT(-0400)] <EricDalquist>
[11:13:06 EDT(-0400)] <EricDalquist> I'll do some digging
[11:13:14 EDT(-0400)] <EricDalquist> that whole package may be left over from ALM related work
[11:43:04 EDT(-0400)] <EricDalquist> wow
[11:43:16 EDT(-0400)] <EricDalquist> the number of assumptions about how ids can be treated is really annoying
[11:44:30 EDT(-0400)] <esm> such as
[11:45:10 EDT(-0400)] <EricDalquist> lots of places in code they are created from ints
[11:45:19 EDT(-0400)] <EricDalquist> then toString'd later
[11:45:22 EDT(-0400)] <EricDalquist> then back to ints
[11:45:38 EDT(-0400)] <EricDalquist> and in many of the unit tests the strings used aren't numbers
[11:45:55 EDT(-0400)] <EricDalquist> just not much consistency as to what the value should/could look like
[11:47:34 EDT(-0400)] * esm nodes
[11:47:40 EDT(-0400)] * esm nods too
[11:48:07 EDT(-0400)] <EricDalquist>
[11:48:16 EDT(-0400)] <EricDalquist> so I think I'm just going to make everything a string
[11:48:17 EDT(-0400)] <esm> I've always thought that the object id would be a private field of an object
[11:48:21 EDT(-0400)] <esm> and not be exposed at all
[11:48:24 EDT(-0400)] <EricDalquist> yeah
[11:48:45 EDT(-0400)] <EricDalquist> we probably do need a public id and a private id
[11:48:52 EDT(-0400)] <EricDalquist> like in up2 we have fnames for channels
[11:49:27 EDT(-0400)] <esm> you may need to create an id used as an argument to construct another object. but you shouldnt' be able to get that id back. and id's should be immutable
[11:51:03 EDT(-0400)] <EricDalquist> hrm
[11:51:09 EDT(-0400)] <esm> people can make all those assumptions about objectid because they all derive from the common implementation (at least, in most cases)
[11:51:17 EDT(-0400)] <EricDalquist> yeah
[11:51:27 EDT(-0400)] <EricDalquist> and a common impl that had far more methods on it than it needed to
[11:51:46 EDT(-0400)] <EricDalquist> the other issue that I have to deal with eventually is the xml import/export side of things
[11:52:14 EDT(-0400)] <esm> there really isn't a contract. it doesn't exist. clients just observe the behavior (or read the source) of the impl and code to it.
[11:52:33 EDT(-0400)] <EricDalquist> and the xml files will need some identifier to reference other objects
[11:53:11 EDT(-0400)] <EricDalquist> but we don't want that to be the ObjectId since that is a db internal key
[11:53:56 EDT(-0400)] <EricDalquist> yeah :/
[11:56:35 EDT(-0400)] <esm> getting rid of the objectid factories and objectid interfaces won't change that aspect of things: the lack of a contract, and the assumptions about how objectids are treated.
[11:56:53 EDT(-0400)] <esm> perhpas less methods on the objectid, unit tests, and javadoc will help