first feeling

[jan]

From google-guice newsgroup:

 

My first feeling about avoding annotations is mixed though. Especially the default constructor inspection feels strange:
"By default the constructor with no parameters is selected (if available) or the 1st (in sequence of definition within the class) with any parameters."

Actually I started with that in the very beginning and never had to change since I use just one constructor having the parameters that are needed.

Definitely nothing that is very decided. 

 

The ordering of constructors is a very subtle way to guide injection, i really like annotations for that. They are a bit more explicit. They serve as documentation and don't
come with a runtime performance penalty.

Annotations come with same performance penalty as inspecting existing constructors. Both is a lookup via reflection. 

Just my personal feeling, and as I understood your documentation, adding annotations should be an easy addition if I desire to do so, right?

Exactly. http://www.silkdi.com/userguide/intro.html#customise You can use *your* annotation very easy if this is what you like. 

Jan

 

[Willi Schönborn]

On Friday, April 5, 2013 1:28:57 PM UTC+2, jan wrote:

From google-guice newsgroup:

 

My first feeling about avoding annotations is mixed though. Especially the default constructor inspection feels strange:
"By default the constructor with no parameters is selected (if available) or the 1st (in sequence of definition within the class) with any parameters."

Actually I started with that in the very beginning and never had to change since I use just one constructor having the parameters that are needed.

Definitely nothing that is very decided. 

I still find it too subtle, because its an important part of your spec. Inexperienced users might overlook it easily. Its like the "package-private" visibility which does not

have a keyword in Java, its easily overlooked in the code, because its not explicit. 

 

The ordering of constructors is a very subtle way to guide injection, i really like annotations for that. They are a bit more explicit. They serve as documentation and don't
come with a runtime performance penalty.

Annotations come with same performance penalty as inspecting existing constructors. Both is a lookup via reflection. 

Agreed when you want to read them, I was referring to the case when you don't want to use DI. Let's assume, somebody uses code written for Guice without using Guice. You can still call constructors etc. directly, without having to worry about the @Inject annotation, so no runtime performance penalty, compared to lets say a Service Locator which one directly accesses in its code. 

Just my personal feeling, and as I understood your documentation, adding annotations should be an easy addition if I desire to do so, right?

Exactly. http://www.silkdi.com/userguide/intro.html#customise You can use *your* annotation very easy if this is what you like. 

That's what I thought ;) 

Jan

 

[Jan Bernitt]

On 05/04/13 15:23, Willi Schönborn wrote:
> On Friday, April 5, 2013 1:28:57 PM UTC+2, jan wrote:

> Agreed when you want to read them, I was referring to the case when you
> don't want to use DI. Let's assume, somebody uses code written for Guice
> without using Guice. You can still call constructors etc. directly,
> without having to worry about the @Inject annotation, so no runtime
> performance penalty, compared to lets say a Service Locator which one
> directly accesses in its code.

Maybe you got that wrong. The hole idea in Silk is to have your
constructor as usual so you don't need the DI framework and not add
no-args constrctors as you usually do with guice when you annotate
fields. In silk you should code as if you have no DI framework. And than
you make it understand how to use the given constructors. That is up to
you as a user. Some might prefer order in file, some to pick most args
first and other like to annotate. Silk urges you do use what you like
and makes it easy to customize that.

Annotations just make sense if there is more than one constructor.
Something I find strange to have since I use factory method for such
cases. But if you think different and have different utility
constructors instead it also appears logical that even with DI you might
want to use different ones for different cases what is a bad match for
annotating one of them.

Anyhow. You definitely have a point that the default strategy should
adapted somehow even if it should be the normal case to use your own.

Jan

[st.cl...@gmx.ch]

"By default the constructor with no parameters is selected (if available) or the 1st (in sequence of definition within the class) with any parameters."

Just a shy question, because I was not able to find the answer on my own.
Is the order of the constructors returned by a call to Class.getConstrucots somehow defined?

The only hint i was able to find was:

    /**
     * Returns an array of <code>Constructor</code> objects reflecting all the
     * constructors declared by the class represented by this
     * <code>Class</code> object. These are public, protected, default
     * (package) access, and private constructors.  The elements in the array
     * returned are not sorted and are not in any particular order.  If the
     * class has a default constructor, it is included in the returned array.
     * This method returns an array of length 0 if this <code>Class</code>
     * object represents an interface, a primitive type, an array class, or
     * void.
     *
     * <p> See <em>The Java Language Specification</em>, section 8.2.
     *
     * @return    the array of <code>Constructor</code> objects representing all the
     * declared constructors of this class
     * @exception  SecurityException
     *             If a security manager, <i>s</i>, is present and any of the
     *             following conditions is met:
     *
     *             <ul>
     *
     *             <li> invocation of
     *             <tt>{@link SecurityManager#checkMemberAccess
     *             s.checkMemberAccess(this, Member.DECLARED)}</tt> denies
     *             access to the declared constructors within this class
     *
     *             <li> the caller's class loader is not the same as or an
     *             ancestor of the class loader for the current class and
     *             invocation of <tt>{@link SecurityManager#checkPackageAccess
     *             s.checkPackageAccess()}</tt> denies access to the package
     *             of this class
     *
     *             </ul>
     *
     * @since JDK1.1
     */
    public Constructor<?>[] getDeclaredConstructors() throws SecurityException {
    // be very careful not to change the stack depth of this
    // checkMemberAccess call for security reasons
    // see java.lang.SecurityManager.checkMemberAccess
        checkMemberAccess(Member.DECLARED, ClassLoader.getCallerClassLoader());
        return copyConstructors(privateGetDeclaredConstructors(false));
    }

which makes me think that there is no particular order defined in the bytecode and therefore I feel it problematic to choose the "first" constructor.

[jan]

Hi,

On Friday, 5 April 2013 17:01:42 UTC+2, st.cl...@gmx.ch wrote:

Is the order of the constructors returned by a call to Class.getConstrucots somehow defined?

 actually...no.

 The elements in the array returned are not sorted and are not in any particular order. 

tldr that

 

which makes me think that there is no particular order defined in the bytecode and therefore I feel it problematic to choose the "first" constructor.

You are absolutely right. 

As said before: I did not get intro trouble with this since I am so used to just have one constructor in my code. I will change docs and impl. to have a more determined behaviour. But it is still just 1 line of code away to pick the constructor however you wan't it. Maybe I should also emphasise this in the docs. 

Thanks for the critical eye.

Jan

[st.cl...@gmx.ch]

Am Freitag, 5. April 2013 17:16:22 UTC+2 schrieb jan:

I will change docs and impl. to have a more determined behavior. But it is still just 1 line of code away to pick the constructor however you wan't it.

I like your reasoning about using only a single constructor and having multiple factory methods for creating an instance in different ways.
Since this is one of your "main" assumptions I would go as far as to have silk throw an exception when encountering more than one constructor.

As you said its a one liner to change the way silk chooses the constructor therefore having a strict default strategy should not keep anybody from using silk.