• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
Locked
0

Private variables make it hard to extend TLF classes

Participant ,
Nov 03, 2009 Nov 03, 2009

Copy link to clipboard

Copied

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? 

TOPICS
Text layout framework

Views

1.4K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Nov 03, 2009 Nov 03, 2009

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Nov 15, 2009 Nov 15, 2009

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Nov 16, 2009 Nov 16, 2009

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Nov 16, 2009 Nov 16, 2009

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Nov 16, 2009 Nov 16, 2009

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Nov 16, 2009 Nov 16, 2009

Copy link to clipboard

Copied

> 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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Nov 16, 2009 Nov 16, 2009

Copy link to clipboard

Copied

LATEST

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines