Hindsight is great !
I am not saying anything was done wrong. I just think the projects
that recognize where the API can be improved and do so in a later
release - when they've had the hindsight - do better long-term.
With decorator and facade classes you may still not get 100% code
compa
robert engels wrote:
Some would argue that all that Field needs is
FieldData getField(String name); and void setField(String name,FieldData
data);
and FieldData has
toBytes(); fromBytes()
Isn't hindsight wonderful!
Writing custom versions of IndexReader and IndexWriter was very
difficult
There have been many major successful libraries where the interfaces
change from one (major) version to the next.
Programmers are used to it, and quite apt at dealing with it.
But, in the cited case, it is a perfect example where Field being an
interface and DefaultField being a default impl
Yeah, I tend to think Open Source development should favor abstract
classes, since there is no way of knowing all the different things so
many varied users will come up with over time. I suppose one could
argue for more "major" upgrades to offset that, or more relaxed rules
about interface
Steven A Rowe wrote:
In the comments on the blog post, the author (Kirill Osenkov) agrees with a dissenter
(Alexander Jung, a.k.a. "AJ.NET"), who re-states the rule of thumb as:
"An interface should define at most one contract."
But what if you want to expand the contract? For example, Field
On 03/24/2008 at 5:32 PM, Doug Cutting wrote:
> Chris Hostetter wrote:
> > in my opinion other blog he links to hits the nail on the head a
> > little better (i remember reading this last year) ...
> >
> http://kirillosenkov.blogspot.com/2007/08/choosing-interface-vs-abstract-class.html
>
> The r
I have to agree with the blog (it terms of interfaces/classes and
'why Lucene isn't all that). Of course, it seems like we have faced
almost the exact same problems.
If you read farther down in the comments there is a very specific
example that explains the problem quite well.
There is al
Chris Hostetter wrote:
in my opinion other blog he links to hits the nail on the head a
little better (i remember reading this last year) ...
http://kirillosenkov.blogspot.com/2007/08/choosing-interface-vs-abstract-class.html
The rule of thumb there is good too:
"An interface should define a
: i enjoy reading Carp's blog, he has/had the same dilemma :) interfaces
: vs abstract classes, nice reading on http://lingpipe-blog.com/
FYI: direct link...
http://lingpipe-blog.com/2008/03/19/abstract-base-classes-vs-interfaces/
in my opinion other blog he links to hits the nail on the head
: IndexReader would not instantiate a subclass in this example. I was just
: saying your wrapping example doesn't require an interface: it works equally
: well if ReadOnlyDocument is a concrete class. I think moving away from
: interfaces for 3.0 makes sense.
i don't know that it works equally
i enjoy reading Carp's blog, he has/had the same dilemma :) interfaces vs
abstract classes, nice reading on http://lingpipe-blog.com/
__
Sent from Yahoo! Mail.
More Ways to Keep in Touch. http://uk.docs.yahoo.com/nowyoucan.html
Chris Hostetter wrote:
: Wouldn't subclassing ReadOnlyDocument also work in this case, if
you override
: the getField* to do your own new logic if it applies else
fallback to super?
Sure, but how will IndexReader (or really FieldsReader) know which
subclass to instantiate?
IndexReader w
: Wouldn't subclassing ReadOnlyDocument also work in this case, if you override
: the getField* to do your own new logic if it applies else fallback to super?
Sure, but how will IndexReader (or really FieldsReader) know which
subclass to instantiate? I think in LUCENE-778 the notion of passing
Can't you just make Document non final and add a property (name of
class) that the reader will call Class.forName().newInstance() when
it needs to create document. As long as subclasses has a no-arg ctor,
what is the problem?
Note, if you allow this kind of support, passing Document instanc
> > IndexableField really shouldn't be a subclass of whatever class is
> > returned after a sarch is done ... the methods used for accessing the
> > "stored" value of a returned document make as little sense in the
> > context of IndexableField as the setBoost/Reader/TokenStream
> > functions of
Chris Hostetter wrote:
: I do like moving towards a separation of Document for indexing vs
: searching for 3.0.
:
: Disregarding for starters how we get there from here...
:
: Wouldn't we just want a base class (not an interface), say
: ReadOnlyField, that is used in documents retrieved by a re
Probably going to disagree here... but that's ok !
I think IndexReader and IndexWriter would have been perfect
interfaces - as long as the concepts were kept very abstract.
putDocument(), getDocument(), findDocument(), etc.
and supported the semantics.
That is what I find is key to hiding t
: I do like moving towards a separation of Document for indexing vs
: searching for 3.0.
:
: Disregarding for starters how we get there from here...
:
: Wouldn't we just want a base class (not an interface), say
: ReadOnlyField, that is used in documents retrieved by a reader? This
: class woul
robert engels wrote:
The problem with abstract classes, is that any methods you provide
"know" something of the implementation, unless the methods are
implemented solely by calling other abstract methods (which is rarely
the case if the abstract class contains ANY private members).
Yes, abstr
Thanks Hoss and Grant for links to all the background on this issue.
I've read through them and now my brain is really fuzzy...
For 1219, I'd rather not introduce yet another interface into the
Field classes. I think it confuses our users to have so many
classes/interfaces to represent the fairly
I disagree on the use the interfaces.
The problem with abstract classes, is that any methods you provide
"know" something of the implementation, unless the methods are
implemented solely by calling other abstract methods (which is rarely
the case if the abstract class contains ANY private m
Chris Hostetter wrote:
Committers tend to prefer abstract classes for extension points because it
makes it easier to support backwards compatibility in the cases were we
want to add methods to extendable APIs and the "default" behavior for
these new methods is simple (or obvious delegation to e
"Well, maybe we should put 1219 off to 3.0 and maybe we should get to
3..0 sooner rather than later, as in stop adding new features and focus
on bug fixes and deprecation. :-)"
honestly, "getting to 3.0 sooner" can take far too long for an itch I currently
have, gc() is kicking in like crazy
- Original Message
From: Grant Ingersoll <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Wednesday, 19 March, 2008 12:01:34 PM
Subject: Re: Fieldable, AbstractField, Field
On Mar 19, 2008, at 6:45 AM, eks dev wrote:
Hoss, thanks for kicking-in with your "desig
ke such changes.
- Original Message
From: Grant Ingersoll <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Wednesday, 19 March, 2008 12:01:34 PM
Subject: Re: Fieldable, AbstractField, Field
On Mar 19, 2008, at 6:45 AM, eks dev wrote:
> Hoss, thanks for kicking-in with you
I do agree, Hoss, that it makes sense to think about an IndexDocument
and a SearchDocument or something along those lines for 3.0.
Also note, I added some comments to 1219 about the history of Fieldable.
On Mar 18, 2008, at 9:26 PM, Chris Hostetter wrote:
: Really, I think we could go just
On Mar 19, 2008, at 6:45 AM, eks dev wrote:
Hoss, thanks for kicking-in with your "design purist" hat on :)
about your proposal,
"The best short term approach I can think of for addressing
LUCENE-1219
in 2.4:
1) list the new methods in a new interface that extends Fieldable
(ByteArrayReu
Hoss, thanks for kicking-in with your "design purist" hat on :)
about your proposal,
"The best short term approach I can think of for addressing LUCENE-1219
in 2.4:
1) list the new methods in a new interface that extends Fieldable
(ByteArrayReuseFieldable or something)
2) add the new met
: Really, I think we could go just back to a single Field class instead
: of the three classes Fieldable, AbstractField and Field. If we had
: this then LUCENE-1219 would be easier to cleanly implement.
It's probably worth reviewing the orriginal reasons why Fieldable and
AbstractField were add
additionaly, this very reason makes something like
Document.getBinaryValue(String name, byte[] myBuffer);, to put it mildly,
impractical. This could be handy way to reduce allocations when fetching as
stored fields can be big
- Original Message
From: Michael McCandless <[EMAIL PRO
30 matches
Mail list logo
