Re: [IronPython] IronPython for Silverlight 5?

2011-04-14 Thread Tomas Matousek 
I think this should be possible in SL4 already:

public abstract class Type : MemberInfo, _Type, IReflect
{
[SecuritySafeCritical]
internal protected Type();
}

There seems to be nothing that would prevent from doing so. 

Tomas

-Original Message-
From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Keith Rome
Sent: Thursday, April 14, 2011 4:15 PM
To: Discussion of IronPython
Cc: Discussion of IronPython
Subject: Re: [IronPython] IronPython for Silverlight 5?

The docs for System.Type claims that you cannot subclass from it in 
Silverlight. Is this being relaxed in v5?


Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS

Wintellect | 770.617.4016 | kr...@wintellect.com

www.wintellect.com

On Apr 14, 2011, at 6:49 PM, "Tomas Matousek"  
wrote:

> Couldn't you just subclass Type? It's methods are virtual and can be 
> overridden. I don't think you need to emit a real RuntimeType.
> 
> Tomas
> 
> -Original Message-
> From: users-boun...@lists.ironpython.com 
> [mailto:users-boun...@lists.ironpython.com] On Behalf Of Keith Rome
> Sent: Thursday, April 14, 2011 3:30 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython for Silverlight 5?
> 
> After looking into what it takes to implement ICustomTypeProvider it seems 
> like it would be a nightmare for dynamic object support. You have to produce 
> actual custom Type instances, presumably using TypeBuilder and emitting IL 
> opcodes to handle the getter/setter accessors. If the databinding system 
> caches those dynamically-created Types then it could cause problems because 
> what happens when we add a new member via expando after binding once (or 
> remove one that previously existed)? But if they don't cache the Type objects 
> then it seems like the overhead might be absurd from constructing these 
> things again and again (and you can't use TypeBuilder without first creating 
> a dynamic assembly and module).
> 
> I really hope they alter course and go with ICustomTypeDescriptor instead (or 
> even IDynamicMetaObjectProvider if that is feasible). I really don't 
> understand how they expect the current system to work for "dynamic 
> properties" because there is nothing dynamic at all about a System.Type 
> instance. The best it can hope to be is a snapshot of the metadata from a 
> dynamic object as of some point in time.
> 
> 
> Keith Rome
> Senior Consultant and Architect
> MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS Wintellect | 
> 770.617.4016 | kr...@wintellect.com www.wintellect.com
> 
> 
> -Original Message-
> From: users-boun...@lists.ironpython.com 
> [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
> Sent: Thursday, April 14, 2011 4:11 PM
> To: Discussion of IronPython
> Cc: Chad Brockman
> Subject: Re: [IronPython] IronPython for Silverlight 5?
> 
> On Thu, Apr 14, 2011 at 11:03 AM, Dino Viehland  wrote:
>> Jeff wrote:
>>> On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman 
>>> wrote:
>>>> I see Silverlight 5 now has something besides simple reflection
>>>> (ICustomTypeProvider) -
>>>> 
>>>> http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data
>>>> 
>>>> Will we see an update to Iron*/DLR to support binding to dynamic 
>>>> objects any time soon? This will open fantastic options for using 
>>>> IronPython in Silverlight.
>>> 
>>> If someone provides a patch, yes.
>>> 
>>> We actually need someone with an interest in Silverlight to keep an 
>>> eye on it and make sure that we don't break SL support and new 
>>> features like this. We don't have anyone in that role right now.
>> 
>> If anyone's interested on working on this it'd probably mean adding 
>> an implementation of this onto OldInstance as well as adding it onto 
>> our new-style instances whose classes are created by NewTypeMaker.  
>> Adding the interface is probably pretty easy, making it return useful things 
>> may be a little more difficult.
>> 
>> I'm a little surprised they didn't go with the already existing 
>> ICustomTypeDescriptor.
> 
> Are you really surprised? :)
> 
> It is still in Beta. Maybe there's a slight chance their minds could be 
> changed? I'm guessing they don't have the rest of System.ComponentModel 
> either, so they didn't want to add just one interface.
> 
> - Jeff
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://

Re: [IronPython] IronPython for Silverlight 5?

2011-04-14 Thread Keith Rome 
The docs for System.Type claims that you cannot subclass from it in 
Silverlight. Is this being relaxed in v5?


Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS

Wintellect | 770.617.4016 | kr...@wintellect.com

www.wintellect.com

On Apr 14, 2011, at 6:49 PM, "Tomas Matousek"  
wrote:

> Couldn't you just subclass Type? It's methods are virtual and can be 
> overridden. I don't think you need to emit a real RuntimeType.
> 
> Tomas
> 
> -Original Message-
> From: users-boun...@lists.ironpython.com 
> [mailto:users-boun...@lists.ironpython.com] On Behalf Of Keith Rome
> Sent: Thursday, April 14, 2011 3:30 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython for Silverlight 5?
> 
> After looking into what it takes to implement ICustomTypeProvider it seems 
> like it would be a nightmare for dynamic object support. You have to produce 
> actual custom Type instances, presumably using TypeBuilder and emitting IL 
> opcodes to handle the getter/setter accessors. If the databinding system 
> caches those dynamically-created Types then it could cause problems because 
> what happens when we add a new member via expando after binding once (or 
> remove one that previously existed)? But if they don't cache the Type objects 
> then it seems like the overhead might be absurd from constructing these 
> things again and again (and you can't use TypeBuilder without first creating 
> a dynamic assembly and module).
> 
> I really hope they alter course and go with ICustomTypeDescriptor instead (or 
> even IDynamicMetaObjectProvider if that is feasible). I really don't 
> understand how they expect the current system to work for "dynamic 
> properties" because there is nothing dynamic at all about a System.Type 
> instance. The best it can hope to be is a snapshot of the metadata from a 
> dynamic object as of some point in time.
> 
> 
> Keith Rome
> Senior Consultant and Architect
> MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS Wintellect | 770.617.4016 
> | kr...@wintellect.com www.wintellect.com
> 
> 
> -Original Message-
> From: users-boun...@lists.ironpython.com 
> [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
> Sent: Thursday, April 14, 2011 4:11 PM
> To: Discussion of IronPython
> Cc: Chad Brockman
> Subject: Re: [IronPython] IronPython for Silverlight 5?
> 
> On Thu, Apr 14, 2011 at 11:03 AM, Dino Viehland  wrote:
>> Jeff wrote:
>>> On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman 
>>> wrote:
>>>> I see Silverlight 5 now has something besides simple reflection
>>>> (ICustomTypeProvider) -
>>>> 
>>>> http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data
>>>> 
>>>> Will we see an update to Iron*/DLR to support binding to dynamic 
>>>> objects any time soon? This will open fantastic options for using 
>>>> IronPython in Silverlight.
>>> 
>>> If someone provides a patch, yes.
>>> 
>>> We actually need someone with an interest in Silverlight to keep an 
>>> eye on it and make sure that we don't break SL support and new 
>>> features like this. We don't have anyone in that role right now.
>> 
>> If anyone's interested on working on this it'd probably mean adding an 
>> implementation of this onto OldInstance as well as adding it onto our 
>> new-style instances whose classes are created by NewTypeMaker.  Adding 
>> the interface is probably pretty easy, making it return useful things may be 
>> a little more difficult.
>> 
>> I'm a little surprised they didn't go with the already existing 
>> ICustomTypeDescriptor.
> 
> Are you really surprised? :)
> 
> It is still in Beta. Maybe there's a slight chance their minds could be 
> changed? I'm guessing they don't have the rest of System.ComponentModel 
> either, so they didn't want to add just one interface.
> 
> - Jeff
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> 
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> 
> 
> 
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] IronPython for Silverlight 5?

2011-04-14 Thread Tomas Matousek 
Couldn't you just subclass Type? It's methods are virtual and can be 
overridden. I don't think you need to emit a real RuntimeType.

Tomas

-Original Message-
From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Keith Rome
Sent: Thursday, April 14, 2011 3:30 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython for Silverlight 5?

After looking into what it takes to implement ICustomTypeProvider it seems like 
it would be a nightmare for dynamic object support. You have to produce actual 
custom Type instances, presumably using TypeBuilder and emitting IL opcodes to 
handle the getter/setter accessors. If the databinding system caches those 
dynamically-created Types then it could cause problems because what happens 
when we add a new member via expando after binding once (or remove one that 
previously existed)? But if they don't cache the Type objects then it seems 
like the overhead might be absurd from constructing these things again and 
again (and you can't use TypeBuilder without first creating a dynamic assembly 
and module).

I really hope they alter course and go with ICustomTypeDescriptor instead (or 
even IDynamicMetaObjectProvider if that is feasible). I really don't understand 
how they expect the current system to work for "dynamic properties" because 
there is nothing dynamic at all about a System.Type instance. The best it can 
hope to be is a snapshot of the metadata from a dynamic object as of some point 
in time.


Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS Wintellect | 770.617.4016 | 
kr...@wintellect.com www.wintellect.com


-Original Message-
From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Thursday, April 14, 2011 4:11 PM
To: Discussion of IronPython
Cc: Chad Brockman
Subject: Re: [IronPython] IronPython for Silverlight 5?

On Thu, Apr 14, 2011 at 11:03 AM, Dino Viehland  wrote:
> Jeff wrote:
>> On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman 
>> wrote:
>> > I see Silverlight 5 now has something besides simple reflection
>> > (ICustomTypeProvider) -
>> >
>> > http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data
>> >
>> > Will we see an update to Iron*/DLR to support binding to dynamic 
>> > objects any time soon? This will open fantastic options for using 
>> > IronPython in Silverlight.
>>
>> If someone provides a patch, yes.
>>
>> We actually need someone with an interest in Silverlight to keep an 
>> eye on it and make sure that we don't break SL support and new 
>> features like this. We don't have anyone in that role right now.
>
> If anyone's interested on working on this it'd probably mean adding an 
> implementation of this onto OldInstance as well as adding it onto our 
> new-style instances whose classes are created by NewTypeMaker.  Adding 
> the interface is probably pretty easy, making it return useful things may be 
> a little more difficult.
>
> I'm a little surprised they didn't go with the already existing 
> ICustomTypeDescriptor.

Are you really surprised? :)

It is still in Beta. Maybe there's a slight chance their minds could be 
changed? I'm guessing they don't have the rest of System.ComponentModel either, 
so they didn't want to add just one interface.

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] IronPython for Silverlight 5?

2011-04-14 Thread Keith Rome 
After looking into what it takes to implement ICustomTypeProvider it seems like 
it would be a nightmare for dynamic object support. You have to produce actual 
custom Type instances, presumably using TypeBuilder and emitting IL opcodes to 
handle the getter/setter accessors. If the databinding system caches those 
dynamically-created Types then it could cause problems because what happens 
when we add a new member via expando after binding once (or remove one that 
previously existed)? But if they don't cache the Type objects then it seems 
like the overhead might be absurd from constructing these things again and 
again (and you can't use TypeBuilder without first creating a dynamic assembly 
and module).

I really hope they alter course and go with ICustomTypeDescriptor instead (or 
even IDynamicMetaObjectProvider if that is feasible). I really don't understand 
how they expect the current system to work for "dynamic properties" because 
there is nothing dynamic at all about a System.Type instance. The best it can 
hope to be is a snapshot of the metadata from a dynamic object as of some point 
in time.


Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS
Wintellect | 770.617.4016 | kr...@wintellect.com
www.wintellect.com


-Original Message-
From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Thursday, April 14, 2011 4:11 PM
To: Discussion of IronPython
Cc: Chad Brockman
Subject: Re: [IronPython] IronPython for Silverlight 5?

On Thu, Apr 14, 2011 at 11:03 AM, Dino Viehland  wrote:
> Jeff wrote:
>> On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman 
>> wrote:
>> > I see Silverlight 5 now has something besides simple reflection
>> > (ICustomTypeProvider) -
>> >
>> > http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data
>> >
>> > Will we see an update to Iron*/DLR to support binding to dynamic 
>> > objects any time soon? This will open fantastic options for using 
>> > IronPython in Silverlight.
>>
>> If someone provides a patch, yes.
>>
>> We actually need someone with an interest in Silverlight to keep an 
>> eye on it and make sure that we don't break SL support and new 
>> features like this. We don't have anyone in that role right now.
>
> If anyone's interested on working on this it'd probably mean adding an 
> implementation of this onto OldInstance as well as adding it onto our 
> new-style instances whose classes are created by NewTypeMaker.  Adding 
> the interface is probably pretty easy, making it return useful things may be 
> a little more difficult.
>
> I'm a little surprised they didn't go with the already existing 
> ICustomTypeDescriptor.

Are you really surprised? :)

It is still in Beta. Maybe there's a slight chance their minds could be 
changed? I'm guessing they don't have the rest of System.ComponentModel either, 
so they didn't want to add just one interface.

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] IronPython for Silverlight 5?

2011-04-14 Thread Jeff Hardy 
On Thu, Apr 14, 2011 at 11:03 AM, Dino Viehland  wrote:
> Jeff wrote:
>> On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman 
>> wrote:
>> > I see Silverlight 5 now has something besides simple reflection
>> > (ICustomTypeProvider) -
>> >
>> > http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data
>> >
>> > Will we see an update to Iron*/DLR to support binding to dynamic
>> > objects any time soon? This will open fantastic options for using
>> > IronPython in Silverlight.
>>
>> If someone provides a patch, yes.
>>
>> We actually need someone with an interest in Silverlight to keep an eye on it
>> and make sure that we don't break SL support and new features like this. We
>> don't have anyone in that role right now.
>
> If anyone's interested on working on this it'd probably mean adding an 
> implementation
> of this onto OldInstance as well as adding it onto our new-style instances 
> whose
> classes are created by NewTypeMaker.  Adding the interface is probably pretty 
> easy,
> making it return useful things may be a little more difficult.
>
> I'm a little surprised they didn't go with the already existing 
> ICustomTypeDescriptor.

Are you really surprised? :)

It is still in Beta. Maybe there's a slight chance their minds could
be changed? I'm guessing they don't have the rest of
System.ComponentModel either, so they didn't want to add just one
interface.

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] IronPython for Silverlight 5?

2011-04-14 Thread Dino Viehland 
Jeff wrote:
> On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman 
> wrote:
> > I see Silverlight 5 now has something besides simple reflection
> > (ICustomTypeProvider) -
> >
> > http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data
> >
> > Will we see an update to Iron*/DLR to support binding to dynamic
> > objects any time soon? This will open fantastic options for using
> > IronPython in Silverlight.
> 
> If someone provides a patch, yes.
> 
> We actually need someone with an interest in Silverlight to keep an eye on it
> and make sure that we don't break SL support and new features like this. We
> don't have anyone in that role right now.

If anyone's interested on working on this it'd probably mean adding an 
implementation
of this onto OldInstance as well as adding it onto our new-style instances whose
classes are created by NewTypeMaker.  Adding the interface is probably pretty 
easy,
making it return useful things may be a little more difficult.

I'm a little surprised they didn't go with the already existing 
ICustomTypeDescriptor.


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] IronPython for Silverlight 5?

2011-04-14 Thread Keith Rome 
The logical thing would seem to be adding ICustomTypeProvider to ExpandoObject 
or DynamicObject, but these are both in System.Core so more or less out of our 
hands. Or has the Silverlight team extended those classes to support this new 
interface (I haven't pulled down the SL5 bits to check)?

And it begs the question of why did the Silverlight team feel we need yet 
another (incompatible) custom type info implementation?


Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS
Wintellect | 770.617.4016 | kr...@wintellect.com
www.wintellect.com


-Original Message-
From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Thursday, April 14, 2011 10:32 AM
To: Discussion of IronPython
Cc: Chad Brockman
Subject: Re: [IronPython] IronPython for Silverlight 5?

On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman  wrote:
> I see Silverlight 5 now has something besides simple reflection
> (ICustomTypeProvider) -
>
> http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data
>
> Will we see an update to Iron*/DLR to support binding to dynamic 
> objects any time soon? This will open fantastic options for using 
> IronPython in Silverlight.

If someone provides a patch, yes.

We actually need someone with an interest in Silverlight to keep an eye on it 
and make sure that we don't break SL support and new features like this. We 
don't have anyone in that role right now.

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] IronPython for Silverlight 5?

2011-04-14 Thread Jeff Hardy 
On Wed, Apr 13, 2011 at 11:14 PM, Chad Brockman  wrote:
> I see Silverlight 5 now has something besides simple reflection
> (ICustomTypeProvider) -
>
> http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data
>
> Will we see an update to Iron*/DLR to support binding to dynamic objects any
> time soon? This will open fantastic options for using IronPython in
> Silverlight.

If someone provides a patch, yes.

We actually need someone with an interest in Silverlight to keep an
eye on it and make sure that we don't break SL support and new
features like this. We don't have anyone in that role right now.

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] IronPython for Silverlight 5?

2011-04-13 Thread Chad Brockman 
I see Silverlight 5 now has something besides simple reflection 
(ICustomTypeProvider) -

http://msdn.microsoft.com/en-us/library/gg986857(v=VS.96).aspx#data

Will we see an update to Iron*/DLR to support binding to dynamic objects any 
time soon? This will open fantastic options for using IronPython in Silverlight.

Thanks -- Chad

Chad Brockman
Production Solutions Architect
cha...@slb.com

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com