That satisfies the maintainable interface requirement without needing to create an additional class. That would probably be a lot easier for anyone maintaining the code to understand without needing an explanation in the comments of both classes. A simple one line comment above the function should do it:

// No implicit setter because of public/internal compiler scoping bug

I appreciate that you’re just pointing out that the compiler is being stupid, and I agree with you. It just feels like your workaround is a little more cumbersome than it needs to be.

The reason for this is that you will couple your code to an instance variable, which cannot later be made into a property (without considerable ugliness).

One of the only good aspects of properties is that you can start with instance variables and add logic as you go without breaking the interface, by referencing the instance variable directly you have side stepped that.

Fair enough, this is such a simple case, and you may ask why bother with trying to adhere so strictly to encapsulation and whatnot? To be honest, I would have been perfectly happy with non-internal getters, or even public instance variables to solve this, but that’s not the point of this article.

The point is to show that the mxmlc compiler cannot handle this situation, and that that can cause problems. In another example, there may not be a quick and dirty work-around.

I’m sorry if I come off a little bit harsh, I do belive your intention to be good.

internal var _largeImageUrl : String;

public function get largeImageUrl( ) : String { return _largeImageUrl; }

As long as you don’t need to do anything in the setter other than set the internal value, you can just make the varible internal rather than private and dispense with the implicit setter completely.

If you need to do something more complex in the setter, that’s a different story and you’d have to go with something like what you suggested.