Gelmiş geçmiş en büyük porno sitemiz olan 2pe de her zaman en kaliteli pornoları sunmayı hedefledik. Diğer video sitemiz olan vuam da ise hd porno ağırlıklı çalışmalara başladık.

  1. #1
    Sencha User
    Join Date
    Nov 2008
    Posts
    38
    Vote Rating
    0
    kht is on a distinguished road

      0  

    Default why most member data private?

    why most member data private?


    hi all!

    before i write my issue just a remark: i find gxt a great lib!

    i have a general question to the implementation of gxt :
    why most member data is kept private?
    this makes me copy/paste code... duplicate and duplicate class by class.

    sample:
    ComboBox ... in initList() you create a PagingToolBar. i cannot override or customize it as it is not created in overrideable method. i cannot access it. i cannot even override the initList() as it is worthless without getting access to the members.

    at least members should be kept protected to allow workarounds.
    sometimes i think on copy the source of gxt into the project and replacing all private to protected :-)

    thanks for your efforts!
    regards, kht

  2. #2
    Ext User
    Join Date
    Apr 2008
    Posts
    376
    Vote Rating
    0
    zaccret is on a distinguished road

      0  

    Default


    Quote Originally Posted by kht View Post
    at least members should be kept protected to allow workarounds.
    I don't agree with you. Fields should be protected or methods overridable only when the risk of breaking things in super classes is low.

  3. #3
    Sencha User
    Join Date
    Nov 2008
    Posts
    38
    Vote Rating
    0
    kht is on a distinguished road

      0  

    Default result is copy/paste programming

    result is copy/paste programming


    Quote Originally Posted by zaccret View Post
    I don't agree with you. Fields should be protected or methods overridable only when the risk of breaking things in super classes is low.
    for some minor things i would agree. but doing this for nearly everything results for me in a shadow copy/pasted gxt. i have to copy/paste program. and that is really not the sense of object orientation.

    e.g. ComboBox has some bugs - e.g. in the height caluclation of the list. i could override the restrict() method but it is private:
    private void restrict() ....

    i have fallen over so many cases that i really get frustrated on gxt. even copy/paste programming does not lead always to success as there are dependencies.

    on the other side: try to change the footer for paged ComboBox. current footer doesnt fit fully if the list is too small. but how can you customize the footer? through all the private stuff there is no possibility.
    again copy/paste copy/paste copy/paste. every bug or design problem inside gxt gets a big big pain.....

    regards, kht

  4. #4
    Ext User
    Join Date
    Oct 2008
    Location
    Frankfurt a.M., Germany
    Posts
    3
    Vote Rating
    0
    H.Morch is on a distinguished road

      0  

    Default


    i find gxt a great lib!
    ...
    why most member data is kept private?
    I completely agree with you. I'm very pleased about GXT.

    But I'm facing the same problems with private methods. I'm working on a Portal where you can add, remove and resize columns. To do so I have to override the onDrag.. methods. But since onDragStart is private, I copy the Portal class and just change the modifier of onDragStart . After that I can derive from my new Portal and build the mutable upon it. Not really the best practice.


    Regards

    Holger

  5. #5
    Ext User
    Join Date
    Apr 2008
    Posts
    376
    Vote Rating
    0
    zaccret is on a distinguished road

      0  

    Default


    Quote Originally Posted by kht View Post
    i have to copy/paste program. and that is really not the sense of object orientation.
    Good point, I fully agree here. I just think that using protected fields should not be globally done.
    Maybe it should for some specific points you are talking about (with ComboBox), therefore I suggest you to ask for specific points and not for the whole API. On the other side, don't forget that the best long term solution is to post issues in the Bugs forum and get them fixed by GXT team.

    Regards.

  6. #6
    Sencha User
    Join Date
    Nov 2008
    Posts
    38
    Vote Rating
    0
    kht is on a distinguished road

      0  

    Default


    Quote Originally Posted by zaccret View Post
    Good point, I fully agree here. I just think that using protected fields should not be globally done.
    Maybe it should for some specific points you are talking about (with ComboBox), therefore I suggest you to ask for specific points and not for the whole API. On the other side, don't forget that the best long term solution is to post issues in the Bugs forum and get them fixed by GXT team.

    Regards.
    yes, agree, best solution is bugfixing by the gxt team.
    but we will have to live that each gxt will also have bugs (i can live with them) and design flaws (i also can live with them as gxt team cannot guess all use cases). no fix can be a long time solution, so bugs and flaws will be reported here......

    so just please let us developers also be part of the game and not knock us out
    "protected" means: usage only by people who wanna change any behavior and not for normal users of a class. i think this should be protection enough.....

    regards, kht

  7. #7
    Ext User
    Join Date
    Apr 2008
    Location
    Lincoln, NE
    Posts
    235
    Vote Rating
    0
    jpnet is an unknown quantity at this point

      0  

    Default


    I agree with the points stated. The GXT developers shouldn't try to guess how the controls will be inherited. Doesn't it not make sense to make the class members protected instead of private?

    -JP

  8. #8
    Ext User
    Join Date
    Apr 2008
    Posts
    30
    Vote Rating
    0
    abickford is on a distinguished road

      0  

    Default


    i'd agree, make things accessible to the developer. when i need a fix, i need it now, not when the GXT team can get it fixed. i'm currently left w/a copy and paste (i.e. fork) that i have to manage just to fix stuff. if i break something in my subclass, too bad for me. i broke it, i'll fix it.

  9. #9
    Sencha - GXT Dev Team darrellmeyer's Avatar
    Join Date
    May 2007
    Location
    Washington, DC
    Posts
    2,242
    Vote Rating
    2
    darrellmeyer is on a distinguished road

      0  

    Default


    We will not make all private members protected as it is not a good idea for many reasons. If you have a specific requests around visibility, you can post what you would like changed and in most cases we will make the change if it makes sense.

  10. #10
    Sencha User
    Join Date
    Nov 2008
    Posts
    38
    Vote Rating
    0
    kht is on a distinguished road

      0  

    Default


    hi darrell,

    you can easily see what should be protected.
    1) if you use eclipse, just move subclasses to other packages and see what is broken. e.g. GridView and its subclasses and nested classes etc.
    2) just make a copy of your class to another package. if this works, it allows as at least copy paste programming without moving class by class often full hierarchies and dependencies to other packages - this softens the big pain.
    3) try to make sample subclasses of your classes and use a different package and see.... i wanted to change history behavior... but you can try make any change in your dispatcher with a subclass.... this was a never ending copy paste story until i had to realize to give up - i ended in switching off history completely.

    generally: if in development mode gxt team uses other packages and then migrate to distination package, and if they make a sample subclass of all classes, then most things should work for us too.

    for me it is a big frustration. never had any project in my 25 years of oo design and development where i was so far from schedule as this project. the server (great groovy/grails but with terrible eclipse plugin) and client (great gxt but with copy paste programming as nearly all is private) both are very nice technologies, but still not mature. and my hands are bound....

    darrell - we are willing to migrate our code with each gxt coming. we have to adopt as some things just will break and some simply will not run after an update. but private leads to real frustration.

    what if you make all protected and mark them as depricated? when programmers are using them, they ask here for removal of depricated for next release..... this would give us the ability to fix bugs on the fly, write them here and immediately continue working.... this would avoid copy/paste programming completely.

    in all cases, regardless how you decide, i would like to thank you for your work. i think this has a nice future beside flash and silverlight.

    regards, kht