Home » Eclipse Projects » Dynamic Languages Toolkit (DLTK) » Signature change for IBuildpathContainer.getBuildpathEntries()
|
| Re: Signature change for IBuildpathContainer.getBuildpathEntries() [message #21873 is a reply to message #21829] |
Tue, 01 April 2008 05:12   |
 Andrei Sobolev
Messages: 72
Registered: July 2009 |
Member |
|
|
Hi Shelby,
> Why has IBuildpathContainer.getBuildpathEntries() been overloaded to expect
> a parameter of IScriptProject?
This allows per project customization of interpreter container, via org.eclipse.dltk.core.interpreterContainerExtension
extension point.
For example for tcl project in interpreter container entry we hold list of tcl package names, used in project. So each
project could contain different set of interpreter libraries.
Also, why was the original, no-parameter
> version retained rather than removed, since DLTK is still in beta?
You are right, I've removed old method. Thanks.
>
> Are IBuildpathContainer instances expected to be reusable across projects
> now? If so, why don't the other methods accept an IScriptProject as well?
No they are not expected to be reusable.
Best regards,
Andrei Sobolev.
|
|
|
| Re: Signature change for IBuildpathContainer.getBuildpathEntries() [message #21918 is a reply to message #21873] |
Tue, 01 April 2008 16:57 |
Shelby Sanders
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
What about the other methods?
I would expect at least getDescription() and getBuiltinProvider() to have
respective output based on the associated project as well.
> Hi Shelby,
>
>> Why has IBuildpathContainer.getBuildpathEntries() been overloaded to expect
>> a parameter of IScriptProject?
>
> This allows per project customization of interpreter container, via
> org.eclipse.dltk.core.interpreterContainerExtension
> extension point.
>
> For example for tcl project in interpreter container entry we hold list of tcl
> package names, used in project. So each
> project could contain different set of interpreter libraries.
>
> Also, why was the original, no-parameter
>> version retained rather than removed, since DLTK is still in beta?
> You are right, I've removed old method. Thanks.
>
>>
>> Are IBuildpathContainer instances expected to be reusable across projects
>> now? If so, why don't the other methods accept an IScriptProject as well?
> No they are not expected to be reusable.
>
> Best regards,
> Andrei Sobolev.
Thank You,
Shelby Sanders
|
|
|
| Re: Signature change for IBuildpathContainer.getBuildpathEntries() [message #22011 is a reply to message #21918] |
Wed, 02 April 2008 09:51 |
Andrei Sobolev
Messages: 72
Registered: July 2009 |
Member |
|
|
Hi Shelby,
> What about the other methods?
Sure. I've added parameter to this methods.
Best regards,
Andrei Sobolev.
>
> I would expect at least getDescription() and getBuiltinProvider() to have
> respective output based on the associated project as well.
>
>
>> Hi Shelby,
>>
>>> Why has IBuildpathContainer.getBuildpathEntries() been overloaded to expect
>>> a parameter of IScriptProject?
>> This allows per project customization of interpreter container, via
>> org.eclipse.dltk.core.interpreterContainerExtension
>> extension point.
>>
>> For example for tcl project in interpreter container entry we hold list of tcl
>> package names, used in project. So each
>> project could contain different set of interpreter libraries.
>>
>> Also, why was the original, no-parameter
>>> version retained rather than removed, since DLTK is still in beta?
>> You are right, I've removed old method. Thanks.
>>
>>> Are IBuildpathContainer instances expected to be reusable across projects
>>> now? If so, why don't the other methods accept an IScriptProject as well?
>> No they are not expected to be reusable.
>>
>> Best regards,
>> Andrei Sobolev.
>
> Thank You,
> Shelby Sanders
>
|
|
|
| Re: Signature change for IBuildpathContainer.getBuildpathEntries() [message #22055 is a reply to message #22011] |
Wed, 02 April 2008 17:03 |
Shelby Sanders
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
Cool. Thanks, Andrei.
> Hi Shelby,
>> What about the other methods?
> Sure. I've added parameter to this methods.
>
> Best regards,
> Andrei Sobolev.
>>
>> I would expect at least getDescription() and getBuiltinProvider() to have
>> respective output based on the associated project as well.
>>
>>
>>> Hi Shelby,
>>>
>>>> Why has IBuildpathContainer.getBuildpathEntries() been overloaded to expect
>>>> a parameter of IScriptProject?
>>> This allows per project customization of interpreter container, via
>>> org.eclipse.dltk.core.interpreterContainerExtension
>>> extension point.
>>>
>>> For example for tcl project in interpreter container entry we hold list of
>>> tcl
>>> package names, used in project. So each
>>> project could contain different set of interpreter libraries.
>>>
>>> Also, why was the original, no-parameter
>>>> version retained rather than removed, since DLTK is still in beta?
>>> You are right, I've removed old method. Thanks.
>>>
>>>> Are IBuildpathContainer instances expected to be reusable across projects
>>>> now? If so, why don't the other methods accept an IScriptProject as well?
>>> No they are not expected to be reusable.
>>>
>>> Best regards,
>>> Andrei Sobolev.
>>
>> Thank You,
>> Shelby Sanders
>>
Thank You,
Shelby Sanders
|
|
|
Goto Forum:
Current Time: Fri Apr 19 01:04:26 GMT 2024
Powered by FUDForum. Page generated in 0.01966 seconds |
] 
Search
Help
Register
Login
Home
