Skip navigation
Currently Being Moderated

Private variables make it hard to extend TLF classes

Nov 3, 2009 9:35 PM

I am making a class that extends EditManager and I wanted to access pendingInsert but it is a private var, so I can not.  Is there a way around this?  Are private vars much better for memory, why not use protected? 

 
Replies
  • Currently Being Moderated
    Nov 3, 2009 11:04 PM   in reply to josh_on

    There's a continuing tension between making member variables protected, and thus part of the public API, vs making them private and leaving them open to change without disruption to client code. We often err on the side of making them private, so where you see places you think we went the wrong way, please let us know what you need, and why you need it.

     

    Are you adding more ways to insert text, and want to set pendingInsert?

     

    - robin

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 15, 2009 1:51 PM   in reply to robin.briggs

    It would be useful if we could get a public getter for the private _numCharsAdded variable in the PasteOperation class.  It is difficult to derive that value by other means and it seems that a public getter there would not have any implications.

     

    The _tScrapUnderSelection private variable in PasteOperation would be another candidate.  When doing post-processing of the paste operation via FLOW_OPERATION_END, it would be useful to be able to determine any elements that were modified or removed as a result of the paste.  Currently we have to handle FLOW_OPERATION_BEGIN and create our own text scrap for the selection and keep that around for our post-paste processing.  Would be nice if we didn't have to create that second text scrap.

     

    In general, where there is information held privately inside of operations that could be useful for those of us who pre/post process operations, it would be good to expose information that we can use to understand the changes the operations are making.  Use of tlf_internal would be acceptable for us also.  A few more examples are _origID in ApplyElementIDOperation and _origStyleName in ApplyElementStyleNameOperation.

     

    Thanks,

    Brent

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 16, 2009 7:20 AM   in reply to brent.arndorfer

    Be careful what you wish for.  From the experience I have had with protected

    variables and functions in TLF, they do change drastically, even more than

    most betas.  Some of the functions I was using were not just modified but

    completely disappeared when I upgraded to later builds.  If adobe feels the

    need to make these variables private, this is one of those times I'd defer

    to them, because this framework is very new and thus very subject to

    change.  That's what we get when we play with the beta for a never before

    released project.

     

    - Daniel Freiman

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 16, 2009 9:16 AM   in reply to Daniel Freiman

    Public/protected variables are longer term commitment for us than tlf_internal - public/protected APIs are reviewed and discussed in a fair amount of detail.  Making these variables tlf_internal would be no problem.  For classes the [ExcludeClass] metadata tag is used as the equivalent of tlf_internal - indicating the class isn't public and open to changes.  Classes can't be assigned to namespaces in AS3 - much as I'd like to do that.  Those two categories (tlf_internal variables and [ExcludeClass] classes) are all use at your own risk and we do feel free to change them at any time.

     

    Regarding changes - when a piece of the implementation is factored poorly I'd much rather fix that then put a band-aid on it.  That's part of the reason you see so much churn.  Then again we are headed into the part of the project in which we're trying to minimize changes.

     

    FWIW I have a set of TextScrap related bugs that don't merge paragraphs properly in various scenarios (cut/copy/paste and undo) I'm about to look at - new section of the code for me - so expect change.

     

    Richard

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 16, 2009 10:48 AM   in reply to rdermer

    Thanks for the reply.  If those could be made tlf_internal, that would be great.  We've been using TLF heavily now for about 14 months and understand that changes to internal functionality are to be expected.  For the most part, the changes are usually positive improvements, and we have been able to deal with those types of changes as they come.

     

    Regarding the upcoming changes related to cut/copy/paste/undo/redo, it would be great if you could post some quick announcements regarding changes going in as a heads-up for those of us out there using existing low-level API's.  It's not always easy to translate the one-line release notes and/or source diffs into a better understanding of what's changed.

     

    Also, if there's any type of feedback that could be helpful as you consider refactoring approaches, I'd be glad to answer any questions you have regarding how we're using existing API's/Operations related to cut/copy/paste/undo/redo and text scrap related issues we've run across.

     

    Thanks,

    Brent

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 16, 2009 2:44 PM   in reply to brent.arndorfer

    > From the experience I have had with protected variables and functions in TLF, they do change drastically, even more than

    most betas.

     

    Adobe reserves the right during betas to change APIs as they undergo internal and external review and we incorporate the feedback that we get. But after TLF is released as 1.0, if its public and protected APIs need to change, they will probably first get formally deprecated for at least one release.

     

    Gordon Smith
    Adobe Flex SDK Team

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 16, 2009 3:31 PM   in reply to GordonSmith

    Of course Adobe needs to change their APIs during a beta.  I'm just saying that, in general, the larger the change from a pervious version, the more unstable a beta API will be.  With TLF, there is no previous version, it's 100% change.  Thus a larger amount of change is completely understandable, necessary, and should be expected by a developer.  From my individual point of view, TLF has hit this expectation.  I wasn't criticizing the TLF team.  I was attempting to offer advice to anyone who may not have considered these issues.

     

    - Daniel Freiman

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points