Re: pivot-toolkit.org

[Greg Brown <gk...@mac.com>]

Moving discussion to pivot-dev - John, you should subscribe to this list if you have not already done so.

>There's plenty of cool inner classes, but there are too many inner classes.
>And the ApplicationContext$DisplayHost (family) are first class examples of
>the kind that really should not be inner classes.   They're too heavy ..

As much as I appreciate the feedback, I don't share your perspective on inner classes.  :-)  Moving DisplayHost out of pivot.wtk would introduce problems, as it currently relies on access to protected methods within that package. It also shares private members of ApplicationContext.

There's nothing inherently "heavy" about inner classes - it really is just another namespace, with some different rules about member access.

>Dropping the heavier inner classes would be a cheap and easy way to cut the
>pivot learning curve by ten or twenty percent..

FYI, DisplayHost is only public for historical reasons - it could (and probably should) be protected. It is not meant to be used by application developers.

Greg

Re: pivot-toolkit.org

[Greg Brown <gk...@mac.com>]

>Greg or John, can you re-post the entire original message?

Here's the original thread:

On Wednesday, March 18, 2009, at 08:53AM, "John Pritchard" <jd...@syntelos.com> wrote:
>There's plenty of cool inner classes, but there are too many inner classes.
>And the ApplicationContext$DisplayHost (family) are first class examples of
>the kind that really should not be inner classes.   They're too heavy ..
>
>Dropping the heavier inner classes would be a cheap and easy way to cut the
>pivot learning curve by ten or twenty percent..
>
>ps ((the graphics code pointed my simple nose toward 'wtk/skin'..
>but of course i can see that moving DisplayHost to "wtk/skin" would not be
>good
>maybe "wtk/context" or "wtk/window"))
>
>
>On Wed, Mar 18, 2009 at 8:41 AM, Greg Brown <gk...@mac.com> wrote:
>
>> DisplayHost is not really part of the skin. It is our "window" (again, no
>> pun) into the native UI. Skins are a different concept.
>>
>> BTW, I don't agree with the "< 10 line" principle - we have lots of inner
>> classes that are longer than 10 lines. To me, inner classes are simply a way
>> to partition your namespace, just like packages.
>>
>> On Wednesday, March 18, 2009, at 08:02AM, "John Pritchard" <
>> jdp@syntelos.com> wrote:
>> ><sanity-warning>
>> >
>> >the "ApplicationContext$DisplayHost" (and peers, no pun intended)
>> definitely needs to move to "wtk/skin"
>> >
>> >(Related truism: any inner class more than ten lines [in Pivot's case]
>> needs to export)
>> >
>> >sometimes your conscience only looks like another person
>> >call it karma
>> >
>> >or.. file under.. "things to do before it's too late"
>> >
>> ></sanity-warning>
>> >
>>
>

Re: pivot-toolkit.org

[Todd Volkert <tv...@gmail.com>]

Greg or John, can you re-post the entire original message?

-T

On Wed, Mar 18, 2009 at 9:07 AM, Greg Brown <gk...@mac.com> wrote:
> Moving discussion to pivot-dev - John, you should subscribe to this list if you have not already done so.
>
>>There's plenty of cool inner classes, but there are too many inner classes.
>>And the ApplicationContext$DisplayHost (family) are first class examples of
>>the kind that really should not be inner classes.   They're too heavy ..
>
> As much as I appreciate the feedback, I don't share your perspective on inner classes.  :-)  Moving DisplayHost out of pivot.wtk would introduce problems, as it currently relies on access to protected methods within that package. It also shares private members of ApplicationContext.
>
> There's nothing inherently "heavy" about inner classes - it really is just another namespace, with some different rules about member access.
>
>>Dropping the heavier inner classes would be a cheap and easy way to cut the
>>pivot learning curve by ten or twenty percent..
>
> FYI, DisplayHost is only public for historical reasons - it could (and probably should) be protected. It is not meant to be used by application developers.
>
> Greg
>
>