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?
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?
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.
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
- 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.
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.
> From the experience I have had with protected variables and functions in TLF, they do change drastically, even more than
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.
Adobe Flex SDK Team
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