Some thoughts.

[Digy]

Just some thoughts about the codes in trunk.

 

* lucere.definition.toolkit.cache

  -this could have  more .NET-like interface

                  void Add(TKey key, TValue value);

                  TValue this[TKey key] { get; set; }

 

* lucere.stream.diagnostic.IStatus

  -Names seem like a method names, rather than properties.

 

* lucere.stream.diagnostic.IFieldNormStatus

  -TotFields --> TotalFields

  -Error --> a method like SetError sounds better.

 

*

  lucere.definition.stream.IByteBlockPool.cs

  lucere.definition.stream.IByteSliceReader

  lucere.definition.stream.IByteSliceWriter

  lucere.definition.stream.IByteBlockPool

  lucere.definition.stream.ICharBlockPool

  -They are not base classes. No need for interfaces

 

* lucere.definition.stream.ITermEnum

  instead of having a method like "bool Next()"

  it could be something like

  "public interface ITermEnum : IEnumerator<ITerm>"

 

 

DIGY

 

[Troy Howard]

DIGY,

Thanks for the feedback. I went ahead and applied those changes and
updated a few more things based on them. All very good suggestions!

Regarding "IByteBlockPool ... They are not base classes. No need for
interfaces":

We are currently creating interfaces for every class, even if it is
not a base class. The goal is to have the entire object model
abstracted into interfaces so that we can test and refactor against
that abstraction without concern for the details of implementation. It
facilitates easier refactoring and mocking during unit testing to
improve the quality of those tests.

There will be a lot of seemingly useless interfaces because of this.

Thanks,
Troy

> --
> You received this message because you are subscribed to the Google Groups
> "Lucere" group.
> To post to this group, send email to luc...@googlegroups.com.
> To unsubscribe from this group, send email to
> lucere+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/lucere?hl=en.
>

[Gokhan Demir]

So at stage-two when we begin the implementation, will these
interfaces which are not abstracted from base classes will be
removed ?
Extracting interfaces for every class a little confused me. Currently
instead of creating interfaces for concrete classes, can't we just
create a mock or stub with exact class name ? (As phase-one no big
redesign of the api will be done, just mirror the lucene)


Gokhan Demir.

[Hakeem]

I see that there are quite a few interfaces named IxxxImpl. I'd think
a name like that would be an implementation of Ixxx rather than it
being an interface itself. Thanks!

[Hakeem]

Oh and also, interfaces have been made of tester programs and there
also are interfaces w/o methods which are corresponding to java
classes that *are * implementing an interface or extending a class.
Examples are all the interfaces except ILock and ILockFactory in
def.io.concurrency. I'd be careful about adding interfaces where a
class was needed so we don't have a clutter later :)

Thanks!

[Sergey Mirvoda]

The idea is

Copy ALL public Lucene API.

Remove\Refactor 

Implement.

Sure XYZImpl it a worst name for interface ever seen:)

as for Concurrency - we already had long discussion.

As you can see in Mercurial history. There were no inheritors form ILock, ILockFactory.

But after discussion with Troy I've implemented that.

Just for later removing for sure.

You received this message because you are subscribed to the Google Groups "Lucere Development" group.
To post to this group, send email to lucer...@googlegroups.com.
To unsubscribe from this group, send email to lucere-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lucere-dev?hl=en.

--
--Regards, Sergey Mirvoda

[Christopher Currens]

The Impl classes/interfaces are awful. There's quite a few of them in
the token attributes section. It may pose a problem changing the
names of those, as my understanding of the future of lucene is to
include those eventually in the index. As it is, the new attribute
system is implemented using reflection, a string is given to the
factory, and the factory find the interface name, and specifically,
the interface name + "impl" and returns that back to the caller. We
may be required to hold onto those horrible names in the future,
whether its on an interface or class. If the attribute name is stored
in the index, we'd need to follow suit, especially in the case of
custom attributes.

> > > > > > lucere+un...@googlegroups.com<lucere%2Bunsu...@googlegroups.com>
> > .

> > > > > > For more options, visit this group at
> > > > > >http://groups.google.com/group/lucere?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lucere Development" group.
> > To post to this group, send email to lucer...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > lucere-dev+...@googlegroups.com<lucere-dev%2Bunsubscribe@googlegrou ps.com>
> > .