You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Eelco Hillenius (JIRA)" <ji...@apache.org> on 2008/10/08 19:53:44 UTC

[jira] Resolved: (WICKET-1862) Please consider backing out changes to Component that merged dissimilar objects into an Object[]

     [ https://issues.apache.org/jira/browse/WICKET-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eelco Hillenius resolved WICKET-1862.
-------------------------------------

    Resolution: Won't Fix

I think we can conclude that the efficiency improvement offsets the hit in readability

> Please consider backing out changes to Component that merged dissimilar objects into an Object[]
> ------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-1862
>                 URL: https://issues.apache.org/jira/browse/WICKET-1862
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 1.3.4
>            Reporter: Willis Blackburn
>            Priority: Minor
>
> In Wicket 1.2, the members of the Component class were pretty straightforward.
> But in 1.3, three fields, including the model, have been merged into a single Object[], and there are new methods called data_get, data_set, data_length, data_add, data_remove, and data_insert, to deal with the array.
> I cannot determine from the source code why this was done, but it does not seem like a change for the better.  The Component class is now very confusing, and the change has also made working with any Component subclass (in other words, practically every Wicket class!) in the debugger more difficult.  I think that when three fields that used to be accessed in a simple and straightforward manner are replaced by 160 lines of code, there needs to be some very compelling reason.
> Maybe the motivation was to reduce the memory footprint of a Component instance that does not have any model, behaviors, or metadata, or maybe one that just has one of the three?  If so, is that really so compelling?  Is the memory footprint that large?  Are users suffering from problems that have been addressed by this solution?  In the context of the memory usage of a typical webapp, saving something like 8 bytes per Component instance does not seem like that much.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.