Re: [e4-dev] E4 Formal API Part 1: Dependency Injection

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

Did you read the blog, IServiceConstants.* is not a replacement for
@Active! Yes @Active is not as easy to understand as @Named but if you
once understood it, it is a very valueable thing.

Tom

Am 06.03.13 16:18, schrieb Eric Moffatt:
> 
> Tom, in what way do they differ ? IMO this is even worse than if they
> were == since it means we (at least *I*..;-) don't even have a clear
> idea of what 'active' means.
> 
> If @Active makes sense does @Named(IServiceConstants.ACTIVE_PART)?
> 
> In either case I think that it still makes sense for us not to declare
> either approach as API based on the 'better safe than sorry' rule.
> 
> Note that I also expect that once we start looking at nested parts we'll
> have to make some revisions to what 'active' means since it could end up
> being a structure of some type.
> 
> Eric
> 
> 
> 
> 
> From: 	Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
> To: 	e4-dev@xxxxxxxxxxx
> Date: 	03/05/2013 12:44 PM
> Subject: 	Re: [e4-dev] E4 Formal API Part 1: Dependency Injection
> Sent by: 	e4-dev-bounces@xxxxxxxxxxx
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> @Active MPart != @Named(IServiceConstants.ACTIVE_PART) MPart
> @Active Shell != @Named(IServiceConstants.ACTIVE_SHELL) Shell
> 
> 
> See http://tomsondev.bestsolution.at/2013/01/30/active-in-e4/so @Active
> makes sense!
> 
> Tom
> 
> Am 05.03.13 16:13, schrieb Eric Moffatt:
>>
>> OK, thanks for the info Jonas. The annotation makes sense but my concern
>> is that we now have two different but equivalent mechanisms to keep
>> synch'd with the active part; @Active and
>> "@Named(_IServiceConstants._/_ACTIVE_PART_/". In general I prefer to
>> avoid this type of duplication so I think I'll mark both patterns as
>> 'provisional' for now and we can come up with an appropriate pattern in
>> Luna.
>>
>> Note that we also have the third mechanism that *will* be API which is
>> to use the EPS 'getActivePart()' method. It's old-school but will be
>> familiar to current eclipse users so it'll do for now (but I'm a
>> complete convert to DI so over time I'd love to get to a point where
>> there are *no* accessors in any service).
>>
>> Folks, this is something good for you all to weigh in on...of the two
>> patterns above which would make more sense for us to standardize on ?
>>
>> Using the explicit annotations is both clearer (and easier to type...;-)
>> but may end up with too many annotations eventually (how many is too
>> many ? don't know).
>>
>> The @Named pattern is quite a bit more flexible in that you don't have
>> to add new annotation interfaces for each.
>>
>> We likely want to use both depending on the particular circumstance but
>> how do we decide which to use ? What we don't want IMO is that it
>> becomes arbitrary, causing our clients to have to search for the right
>> one or having to duplicate everything in both styles...
>>
>> Onwards,
>> Eric
>>
>>
>> From:                  Jonas Helming <jonas.helming@xxxxxxxxxxxxxx>
>> To:                  E4 Project developer mailing list
> <e4-dev@xxxxxxxxxxx>
>> Date:                  03/04/2013 05:47 PM
>> Subject:                  Re: [e4-dev] E4 Formal API Part 1:
> Dependency Injection
>> Sent by:                  e4-dev-bounces@xxxxxxxxxxx
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Hi,
>> you write that @Active is not used. I actually use it quite frequently,
>> e.g. to retrieve the active part. So I would prefer it to be API if
>> possible.
>> Cheers
>> Jonas
>>
>> Am 04.03.2013 22:21, schrieb Eric Moffatt:
>>
>> It's amazing what a week's vacation will do...;-).
>>
>> I've updated the wiki at _http://wiki.eclipse.org/Eclipse4/API/DI_to
>> contain the current set of API that we expect to formalize within the
>> next couple of weeks. I encourage anybody who's interested to go there
>> and check it out...especially for things that I may have missed...if it
>> is *not* on that page then will won't be API (at least for Kepler).
>>
>> Comments welcome...
>>
>> I'll try to get something similar put together for the Mode tomorrow and
>> then on to the various services...
>> Eric
>>
>>
>>
>> _______________________________________________
>> e4-dev mailing list
>> _e4-dev@eclipse.org_ <mailto:e4-dev@xxxxxxxxxxx>
>> _https://dev.eclipse.org/mailman/listinfo/e4-dev_
>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
>>
>>
>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
> 
> 
> -- 
> B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
> ------------------------------------------------------------------------
> tom schindl                 geschäftsführer/CEO
> ------------------------------------------------------------------------
> eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
> http://www.BestSolution.at <http://www.bestsolution.at/>               
>      phone    ++43 512 935834
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
> 
> 
> 
> 
> 
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
> 


-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834