Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

[02:17:06 EDT(-0400)] * esm (n=esm@esm.qis.net) has left ##uportal
[07:14:00 EDT(-0400)] * edalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[08:48:11 EDT(-0400)] * esm (n=esm@clue.mse.jhu.edu) has joined ##uportal
[10:44:34 EDT(-0400)] <EricDalquist> hey
[11:06:11 EDT(-0400)] * pberry (n=pberry@waldorf.CSUChico.EDU) has joined ##uportal
[11:07:19 EDT(-0400)] <pberry> andrew_petro_ubu remind me of Pere Ubu http://www.last.fm/music/Pere+Ubu
[11:41:07 EDT(-0400)] <EricDalquist> how goes the IObjectId work esm?
[11:43:03 EDT(-0400)] <esm> EricDalquist: good i think. unit tests pass. I need to actually build and deploy the war (i ran out of time last night)
[11:43:49 EDT(-0400)] <EricDalquist> I was thinking on the way in to work this morning about why the id interfaces are even there (this is stuff done before I was involved with uP3 so I don't know all the reasons)
[11:43:59 EDT(-0400)] <esm> yeah exactly.
[11:44:05 EDT(-0400)] <EricDalquist> The only thing I can really think of is just to have strongly typed IDs
[11:44:06 EDT(-0400)] <esm> exactly exaclty exactly
[11:44:09 EDT(-0400)] <esm> yeah
[11:44:17 EDT(-0400)] <EricDalquist> but then I'm not sure why we need the big heirarchy
[11:44:20 EDT(-0400)] <esm> right
[11:44:28 EDT(-0400)] <EricDalquist> since the interfaces are specific to the type of object
[11:44:38 EDT(-0400)] <esm> you can still have strongly typed id's if you want, but encapulated in the impl.
[11:44:38 EDT(-0400)] <EricDalquist> like portlet deployment ids are strings
[11:44:44 EDT(-0400)] <EricDalquist> all the other portlet ids are longs
[11:44:44 EDT(-0400)] <esm> that was what my first cut was about.
[11:45:21 EDT(-0400)] <esm> EricDalquist: i gotta run to lunch, it will probably be a couple hours. But lets discuss later?
[11:45:54 EDT(-0400)] <esm> peter cited method names and class names make for clarity
[11:46:03 EDT(-0400)] <esm> but ... the hierarchy is... hmm
[11:46:04 EDT(-0400)] <esm> anyway
[11:46:07 EDT(-0400)] <esm> back in a bit
[11:46:12 EDT(-0400)] <EricDalquist> k
[12:13:20 EDT(-0400)] <pberry> Nice...my JIRA presentation will be roundtable instead of lecture style
[12:13:26 EDT(-0400)] <EricDalquist> cool
[12:14:02 EDT(-0400)] <pberry> it will be interesting to see if the recent trend of "lots of new people" will continue with this JA-SIG
[15:30:58 EDT(-0400)] <EricDalquist> back from the meeting?
[15:31:23 EDT(-0400)] <esm> yeah
[15:31:28 EDT(-0400)] <esm> what's happening
[15:31:35 EDT(-0400)] <esm> i finally got my disk array to work correctly
[15:31:37 EDT(-0400)] <EricDalquist> just finishing up the chaching changes
[15:31:41 EDT(-0400)] <EricDalquist> caching
[15:31:41 EDT(-0400)] <esm> cool
[15:31:57 EDT(-0400)] <EricDalquist> noticed I had to fix a few files in the branch that didn't have their imports set right
[15:32:03 EDT(-0400)] <EricDalquist> are you planning on commiting that fix?
[15:32:09 EDT(-0400)] <EricDalquist> just so I don't cause a merge issue
[15:33:02 EDT(-0400)] <esm> ah, hum. I didn't catch that thanks for letting me know.
[15:33:08 EDT(-0400)] <esm> sure I will fix that.
[15:33:10 EDT(-0400)] <EricDalquist> np
[15:34:30 EDT(-0400)] <EricDalquist> once I get this in we'll have spring aop based declarative caching support
[15:34:39 EDT(-0400)] <esm> nice
[15:36:17 EDT(-0400)] <esm> were the imports preventing you from compiling?
[15:36:26 EDT(-0400)] <EricDalquist> yeah
[15:36:32 EDT(-0400)] <EricDalquist> but I was smart enough to fix them (wink)
[15:36:44 EDT(-0400)] <esm> huh.
[15:36:52 EDT(-0400)] <esm> i just updated and ran mvn compile with no errors.
[15:36:58 EDT(-0400)] <esm> let me dig some more
[15:37:17 EDT(-0400)] <EricDalquist> weird
[15:37:23 EDT(-0400)] <EricDalquist> are you all synced?
[15:37:57 EDT(-0400)] <esm> esm@clue:~/workspace/up3-refactor$ svn info
[15:37:57 EDT(-0400)] <esm> Path: .
[15:37:57 EDT(-0400)] <esm> URL: https://developer.ja-sig.org/svn/up3/branches/maven-refactor
[15:37:57 EDT(-0400)] <esm> Repository Root: https://developer.ja-sig.org/svn
[15:37:57 EDT(-0400)] <esm> Repository UUID: f5dbab47-78f9-eb45-b975-e544023573eb
[15:37:59 EDT(-0400)] <esm> Revision: 11933
[15:38:01 EDT(-0400)] <esm> Node Kind: directory
[15:38:03 EDT(-0400)] <esm> Schedule: normal
[15:38:05 EDT(-0400)] <esm> Last Changed Author: esm
[15:38:07 EDT(-0400)] <esm> Last Changed Rev: 11933
[15:38:09 EDT(-0400)] <esm> Last Changed Date: 2007-04-05 02:41:28 -0400 (Thu, 05 Apr 2007)
[15:38:11 EDT(-0400)] <esm> Properties Last Updated: 2007-04-02 13:32:48 -0400 (Mon, 02 Apr 2007)
[15:38:13 EDT(-0400)] <esm> esm@clue:~/workspace/up3-refactor$ svn st -u
[15:38:15 EDT(-0400)] <esm> ? svn-commit.tmp
[15:38:17 EDT(-0400)] <esm> Status against revision: 11933
[15:38:19 EDT(-0400)] <esm> esm@clue:~/workspace/up3-refactor$
[15:38:21 EDT(-0400)] <esm> yeah
[15:38:23 EDT(-0400)] <esm> let me clean out and re-check this
[15:38:27 EDT(-0400)] <EricDalquist> k
[15:38:33 EDT(-0400)] <EricDalquist> I may have missed it too
[15:38:36 EDT(-0400)] <EricDalquist> I'll double check
[15:38:43 EDT(-0400)] <esm> a little rm -rf in my maven 2 repo... (smile)
[15:38:49 EDT(-0400)] <EricDalquist> did you run the tests
[15:38:54 EDT(-0400)] <EricDalquist> I think it may have been in a unit test
[15:38:54 EDT(-0400)] <esm> yeah
[15:38:56 EDT(-0400)] <esm> oh
[15:38:59 EDT(-0400)] <esm> oH
[15:39:02 EDT(-0400)] <esm> ah one sec
[15:39:17 EDT(-0400)] <esm> i ran tests before i committed but ... maybe i forgot to svn add a new file
[15:39:21 EDT(-0400)] <esm> i always forget that.
[15:39:59 EDT(-0400)] <EricDalquist> (smile)
[15:40:37 EDT(-0400)] <esm> ok yeah I see it :/
[15:42:16 EDT(-0400)] <esm> I got my Joost invite.
[15:42:27 EDT(-0400)] <esm> it turns out it can't run on a Power PC mac. it requires intel.
[15:43:50 EDT(-0400)] <EricDalquist> brb
[15:44:29 EDT(-0400)] <esm> ok fixed.
[15:52:47 EDT(-0400)] <EricDalquist> cool
[15:53:34 EDT(-0400)] <EricDalquist> so ... want to talk about object ids?
[15:53:48 EDT(-0400)] <esm> sure
[15:53:53 EDT(-0400)] <esm> i've got some time now
[15:54:00 EDT(-0400)] <EricDalquist> k
[15:54:07 EDT(-0400)] <EricDalquist> so first I guess I'd like to get your thoughts
[15:55:20 EDT(-0400)] <esm> My thoughts are that the object id hierarchy could be avoided I think.
[15:56:03 EDT(-0400)] <EricDalquist> just have a I*Id interface for each object that wants a strongly typed ID
[15:56:25 EDT(-0400)] <esm> so... why do object need the strongly typed ID?
[15:56:57 EDT(-0400)] <EricDalquist> even that I'm not so sure about
[15:57:02 EDT(-0400)] <EricDalquist> other than clarity in the code
[15:57:05 EDT(-0400)] <EricDalquist> but even then
[15:57:20 EDT(-0400)] <esm> Ok right there is that, my only other thought was equals() and/or hashcode() behavior.
[15:57:23 EDT(-0400)] <EricDalquist> I'm not sure how much value we really get from them
[15:57:25 EDT(-0400)] <esm> and toString().
[15:57:31 EDT(-0400)] <EricDalquist> yeah
[15:58:16 EDT(-0400)] <EricDalquist> hrm
[15:58:23 EDT(-0400)] <EricDalquist> I might email peter about this just to get his thoughts
[15:58:24 EDT(-0400)] <esm> But, I believe you can hide all of that behind an AbstractFactory, as long as clients are willing to use AbstractFactory.createId("foo") instead of AbstractFactory.createUserId("foo");
[15:58:38 EDT(-0400)] <esm> well
[15:59:17 EDT(-0400)] <esm> AbstractFactory.createId(Class, String)
[15:59:21 EDT(-0400)] <esm> so ...
[15:59:51 EDT(-0400)] <EricDalquist> ah
[15:59:51 EDT(-0400)] <esm> clients who care about "strong types" - that is, they need an object Id with specific equals/hashcode/tostring semantics - use
[16:00:02 EDT(-0400)] <EricDalquist> that makes sense
[16:00:11 EDT(-0400)] <esm> AbstractId.createId(IUserId.class, key);
[16:00:26 EDT(-0400)] <esm> dang it
[16:00:43 EDT(-0400)] <esm> AbstractIdFactory.createId(IUserId.class, "foo");
[16:00:44 EDT(-0400)] <esm> but
[16:00:51 EDT(-0400)] <esm> the client has to cast the result back
[16:01:15 EDT(-0400)] <esm> i don't know generics well enought to know if they can help with that or not
[16:01:28 EDT(-0400)] <EricDalquist> I think they might be able to
[16:01:39 EDT(-0400)] <EricDalquist> but we may end up having to have a base interface again
[16:01:50 EDT(-0400)] <esm> AbstractIdFactory can only return the least common denominator (again, not thinking of generics) - IObjectId
[16:01:52 EDT(-0400)] <EricDalquist> I think it could return something like ? extends IObjectID
[16:01:55 EDT(-0400)] <esm> yeah
[16:02:15 EDT(-0400)] <EricDalquist> AbstractIdFactory would be an abstract class then?
[16:02:20 EDT(-0400)] <EricDalquist> and createId would be static?
[16:02:56 EDT(-0400)] <esm> I think so, what do you think? Optionally... we could have I*IdFactory interfaces with impls that use the AbstractIdFactory
[16:03:12 EDT(-0400)] <esm> i have a couple of diagrams written down, which I coudl easily put up on the wiki
[16:03:13 EDT(-0400)] <EricDalquist> hrm
[16:03:19 EDT(-0400)] <EricDalquist> let me think about it for a few minutes
[16:04:22 EDT(-0400)] <esm> basically a digram showing where we were prior to the work done in UPT-268, where we are now
[16:04:52 EDT(-0400)] <esm> adding I*IdFactory interfaces plus impls really adds quite a bit of, well, crufty code just to support strongly typed interfaces.
[16:05:19 EDT(-0400)] <EricDalquist> yeah
[16:05:26 EDT(-0400)] <esm> the most important thing in all of these classes/interfaces is the behavior of toString, equals, and hashcode
[16:05:29 EDT(-0400)] <EricDalquist> simpler==better imho
[16:05:34 EDT(-0400)] <esm> which was on ObjectIdImpl
[16:05:41 EDT(-0400)] <esm> but which I've moved to AbstractObjectIdImpl
[16:06:00 EDT(-0400)] <esm> er
[16:06:05 EDT(-0400)] <esm> AbstractObjectId
[16:06:17 EDT(-0400)] <EricDalquist> yeah, I've been a bit iffy about the methods on IObjectId too
[16:06:23 EDT(-0400)] <EricDalquist> I really don't like it having the toInt/toLong
[16:06:27 EDT(-0400)] <esm> ok sure we can revist those as well
[16:06:28 EDT(-0400)] <esm> right
[16:06:31 EDT(-0400)] <EricDalquist> since those only work for some ids
[16:06:43 EDT(-0400)] <esm> yeah
[16:07:07 EDT(-0400)] <esm> I woudl suggest that the Id's shoudl only have a string representation.
[16:07:09 EDT(-0400)] <EricDalquist> yeah I'd like to see the diagrams if possible
[16:07:19 EDT(-0400)] <esm> ok i will put them up tonight
[16:07:25 EDT(-0400)] <EricDalquist> well I think the root IObjectId should just be .toString()
[16:07:34 EDT(-0400)] <esm> double check them though to make sure they are accurate
[16:07:44 EDT(-0400)] <esm> right, just a .toString().
[16:07:47 EDT(-0400)] <EricDalquist> and class specific Ids (if we still have them) could have toInt/toLong/toFoo
[16:08:04 EDT(-0400)] <esm> if clients need something specific, they can deal with converting the string to an int...
[16:09:02 EDT(-0400)] <EricDalquist> I can't run site on the project right now ... findbugs dies with an outofmemory exception
[16:09:02 EDT(-0400)] <esm> I think there is also a place in this for CompositeObjectId as well
[16:09:03 EDT(-0400)] <EricDalquist> (tongue)
[16:09:07 EDT(-0400)] <esm> LOL
[16:12:51 EDT(-0400)] <esm> EricDalquist: i'm heading home a little early today. I'll throw those diagrams up this evening
[16:12:59 EDT(-0400)] <EricDalquist> cool
[16:13:03 EDT(-0400)] <esm> probably under the maven 2 page
[16:13:07 EDT(-0400)] <EricDalquist> I'm going to commit my caching changes now
[16:13:17 EDT(-0400)] <esm> sweet
[16:13:21 EDT(-0400)] <EricDalquist> I'll start poking around more with the object id ideas you brought up
[16:13:35 EDT(-0400)] <EricDalquist> and see what I can come up with for requirements and such
[16:13:37 EDT(-0400)] <esm> (smile) thanks that would help to get another mind on this
[16:13:43 EDT(-0400)] <EricDalquist> (smile)
[16:13:54 EDT(-0400)] <esm> excellent, well i will talk to you tomorrow if not before
[16:45:55 EDT(-0400)] <EricDalquist> esm if you read the logs this works as hoped: "public static <T extends IObjectId> T createId(Class<T> clazz, String id)"
[16:46:16 EDT(-0400)] * EricDalquist loves generics (and would even more if they actually become a bytecode feature)

  • No labels