Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Dynamic Languages Toolkit (DLTK) » Signature change for IBuildpathContainer.getBuildpathEntries()
Signature change for IBuildpathContainer.getBuildpathEntries() [message #21829] Mon, 31 March 2008 21:35 Go to next message
Shelby Sanders is currently offline Shelby SandersFriend
Messages: 13
Registered: July 2009
Junior Member
All,

Why has IBuildpathContainer.getBuildpathEntries() been overloaded to expect
a parameter of IScriptProject? Also, why was the original, no-parameter
version retained rather than removed, since DLTK is still in beta?

Are IBuildpathContainer instances expected to be reusable across projects
now? If so, why don't the other methods accept an IScriptProject as well?

Thank You,
Shelby Sanders
Re: Signature change for IBuildpathContainer.getBuildpathEntries() [message #21873 is a reply to message #21829] Tue, 01 April 2008 05:12 Go to previous messageGo to next message
Andrei Sobolev is currently offline Andrei SobolevFriend
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 Go to previous messageGo to next message
Shelby Sanders is currently offline Shelby SandersFriend
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 Go to previous messageGo to next message
Andrei Sobolev is currently offline Andrei SobolevFriend
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 Go to previous message
Shelby Sanders is currently offline Shelby SandersFriend
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
Previous Topic:tcl debugging with dltk
Next Topic:Query regarding DLTK JRubySourceParser
Goto Forum:
  


Current Time: Tue Dec 10 16:00:26 GMT 2024

Powered by FUDForum. Page generated in 0.04545 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top