I noticed this Windows-added code in a legacy *.cs file (prior to the advent of partial classes which evicted suchlike from the code files; specifically, this is in an old Windows CE project):
private System.Windows.Forms.Label lblDescription;
public System.Windows.Forms.TextBox txtItemDollar;
Why would some controls be private and others public? It's not the type of control that's the difference, because I see both TextBoxes and Labels that are in some cases private and in others public.
That's kind of academic, I guess; the more pertinent question is: what impact or import do these controls have by having one visibility specifier or the other?
I can understand a private control on what's effectively a compound component.
That's just you want to display something in label, but you don't want to provide the facility to mess with it, change the font, move it etc.
The public member, well that's just wrong.
Someoojah.txtItemDollar.Dispose;
or = null;
If it didn't fall over in a big heap after that I'd be very surprised. It violates so many fundamental design principals, its not true.
Can't say I'm surprised though. Early .net suffered from a number of very poor implementations, probably had a sales deadline to meet.
Related
Declaring members as published has advantages over public:
Ability to read/write the member in the Object Insepoctor of the IDE
RTTI and its uses
So is there ever a benefit to declaring members public instead of published? Does published have any downsides? Or should I always declare members published, as a rule?
PS: Not a duplicate; I read that question and all its answers prior to posting my question. The "possible duplicate" question explains the difference between the two keywords, but doesn't gives guidance when either should be used, or the advantages/disadvantages of using either.
Declaring as published imposes a storage cost because the size of your executable is swollen to contain the RTTI. Declaring as public avoids that cost. It's unlikely that would ever matter, especially given the immense size of modern Delphi executables, containing as they do huge amounts of code that never even executes.
For components that can be edited in the Object Inspector, the difference between public and published is more significant. As you say, this is how a component determines which properties are visible in the Object Inspector. Some properties should be visible there, others not. User "TLama" gives fine examples of properties that need to be public, but should not be editable in the Object Inspector: Parent, Handle and so on.
Beyond that it comes down to opinion. It's entirely up to you to decide what to do.
Assuming there are a few classes, each using something like the following code to protect their area.
static pthread_mutex_t _mutex = PTHREAD_MUTEX_INITIALIZER;
[..]
pthread_mutex_lock(&_mutex);
//some code
pthread_mutex_unlock(&_mutex);
The question:
Do all these classes share the same mutex (so if s/o locks the mutex no one else will be able to access the protected area). Or does every PTHREAD_MUTEX_INITIALIZER create a new mutex?
Literature seems to be ambiguous about this topic, depending on the system PTHREADS is running on.
This has nothing to do with the PTHREAD_MUTEX_INITIALIZER (or even Pthreads) and cannot be system dependent.
This is a basic C++ language question. You're using a static variable so there is only one of it. You haven't shown enough code to know if it's a static member of a class (so there's one _mutex per class type, not per object) or a global static (so there's one _mutex per file).
How do I edit a compiled spritefont? I'd like to change the kerning of some characters, erase a pixel or two, change aliasing, but I couldn't find any official tools that are still supported or are widely known.
If there is no way (or if it's too hard) to edit a compiled spritefont, how do I create spritefont manually?
There is no official way to do this. You will notice that if you look at the SpriteFont type there is precious little you can modify (DefaultCharacter, Spacing and LineSpacing).
And if you look at its content-pipeline counterpart, SpriteFontContent, there are no public members at all.
Your best bet is to use ILSpy to see what private members those classes have (and how they work). And then modify them directly using reflection. SpriteFont is basically a bunch of metrics data and a Texture2D.
I recommend you make a content pipeline extension and modify the SpriteFontContent when you build it (this becomes trickier if you've got an XNB file that you didn't build yourself). It will look something like this:
[ContentProcessor(DisplayName = "Custom Font Processor")]
public class CustomFontProcessor : FontDescriptionProcessor
{
public override SpriteFontContent Process(FontDescription input, ContentProcessorContext context)
{
SpriteFontContent output = base.Process(input, context);
// ... your modifications here ...
return output;
}
}
To make your life easier, you could use Exposed Object which gives you a dynamic that you can then access private members directly on (making it easier to write this reflected code).
You could look at the Nuclex TrueType Importer, which implements its own sprite font processor. It's open source (albiet C++/CLI) so you can examine what it does and perhaps modify it. It includes its own version of SpriteFontContent, but sadly it is similarly locked down. The most important thing Nuclex will give you is it has comments that describe what the different metrics in the sprite font mean.
Obviously you're messing with the private parts of XNA - so don't expect it to keep working between different XNA versions. (The reason it is all private in the first place is so that the XNA team is free to modify it in the future.)
The other thing you could do is to use an alternate tool to build your font as a "Font Texture" (described here - although this article is quite old).
Just recently, probably because I've been maintaining some old code, I've started to look at how / why I do things. As you do.
Most of my Delphi programming has been picked up in house, or from examples scattered across the web or manuals. And in some things are done just because "that's how I do it"
What I'm currently wondering about is Declaration, of variables, procedures, functions, etc.
When I am working with a form, I will place all my procedures and functions under public or private. Whilst I will try to avoid global vars and constants will generally go under var or const, either in the interface or implementation, depending on where they need to be called (occasionally though they will go in public / private)
Otherwise, if its just a unit I will declare the procedure in the interface and use in the implementation. Some of the code I've been maintaining recently has no interface declaration but instead has everything properly ordered with calls after procedures...
Is there a correct way to do this? Are there rules of what should / should not go in the class? Or is it a style / when you started thing?
Edit to add
My question is not about whether a declaration of a procedure goes in private/public but whether all declarations in a TForm Unit should go in one of these. Similarly should var / const be in one or the other?
Further clarification
I understand that not declaring in interface, or declaring in public/private/etc affects the visibility of procedures/functions to other units in my applicaiton.
The core of my question is why would i not want to declare? - especially when working in a form/unit when placing in private is much more explicit that the thing declared is not available to other units...
Cheers
Dan
Everything that can have a different value depending on the concrete instance belongs to the class, i.e.
TDog = class
strict private
FColor : TColor;
FName : String;
public
property Color : TColor read FColor write FColor;
property Name : String read FName write FName;
end;
Color and name are clearly attributes of each dog (and each dog will have other values here).
General rules:
Fields belong in private (visible in this class and in this unit) or strict private (visible only in this class)
If you need access to fields from other classes, create a public property. This gives you the freedom to change the simple field access to a more sophisticated getter / setter method lateron without changing the interface of your class.
Everything should be as local as possible. If private is enough, there's no need to make it protected (visible in subclasses too). And only make those things public that you really need from the outside.
Forms: only those things that you want to be stored in the DFM file should be published.
Put as much as you can in the implementation section and as little as you can in the interface section. This is also true for uses clauses.
You might be confusing the term global variable. If it's declared in a class it's not a global variable (even if declared public). Global variables (which you correctly consider good to avoid) always go in a var section either in the interface or the implementation section (which is preferrable following the general rules above)
The question seems to deal with scope. In other words, how easily accessible things can or should be.
As a general guideline, you want to reduce the scope of things as much as possible but still keep them accessible enough to be reused. The reason for this is:
that as your system grows and becomes more complex, the things that have are larger scope are more easily accessible.
as a result, they are more likely to be reused in an uncontrolled fashion.
(sounds great) but the problem comes when you want to make changes, and many things use that which you want to change...
it becomes far more difficult to make your changes without breaking something else.
Having said that, there is also a distinction between data (variables, constants, class fields, record attributes) and routines (functions, procedures, methods on classes). You'll want to apply the guidelines far more strictly to data because 'strange use' of data could interfere with some of your routines in highly unexpected and hard to debug ways.
Another thing to bear in mind is the special distinction between global variables and class fields or record attributes:
using global variables there is only one 'value' (term used loosely) for the entire application.
using class fields or record attributes, each new instance of the class or record has its own values independent of other instances.
This does seem to imply that you could use some form of global whenever your application only needs one thing. However, as alluded to earlier: this is not the only reason to avoid globals.
Personally I even tend to avoid global routines.
I'm frequently discovering that things that seemed okay declared global are not as universal as first thought. (E.g. Delphi VCL declares a global Screen object, I work on 2 screens; and many of our clients use 4 to 6.)
I also find it useful to associate routines that could have been global with specific classes as class methods. It generally makes it easier to understand the code.
So listing these 'locations' from largest scope to smallest, you would generally strive to pick locations lower down in the list (especially for data).
interface global
implementation global
interface threadvar
implementation threadvar
published (Note I don't really consider this to be a scope identifier; it's really public scope; "and includes RTTI information" - theoretically, it would be useful to also mark some private attributes as "include RTTI".)
public
protected
private
strict private
local variable
I must confess: what I have presented here is most certainly an over-simplification. It is one thing to know the goals, another to actually implement them. There is a balancing act between encapsulation (hiding things away) and exposing controlled interfaces to achieve high levels of re-usability.
The techniques to successfully balance these needs fall into a category of far more complicated (and sometimes even contentious) questions on system design. A poor design is likely to induce one to expose 'too much' with 'too large' a scope, and (perhaps paradoxically) also reduce re-usability.
What about a feature in an upcoming Delphi version enabling that?
Maybe it could be a compiler switch promoting all **private**s to **strict private**s.
... or it could be a feature of the new non-legacy compiler font-end Nick Hodges was talking about. => private does always behave like strict private.
EDIT: The reason why I want this is because I just don't want to add thousands of stricts to my private modifiers. Furthermore the "strict private" behavior is the default behavior in any object oriented language I'm familiar with!
To quote from the article:
So, we are working to create a “new Delphi” and a new compiler architecture, to keep your existing code working, to emit 64-bit binaries using both Delphi and C++Builder, and maybe a few other kind of binaries while we are at it. And it all has to be done right so that it all works for you.
I interpret that as, if codegear is going to change the behaviour of private. Then they wil proide an option to keep the old behaviour just like they did in the past.
Just for clarification, within a class there are 6 different access levels (ok 7 but automated is deprecated).
public: Anything that can access the object can access this.
protected: Methods in the class and its subclasses and anything in the same unit can access.
strict protected: Methods in the class and its subclasses can access.
private: Methods in the class and anything in the same unit can access.
strict private: Methods in the class.
published: As public buth with runtime information for the object inspector.
The current private implementation is private to everything outside the unit it is declared in. So if your reasoning for not wanting to add the strict statements is that you don't want to modify your existing units, then you have nothing to gain except breaking any existing code that accesses the class in the same unit. As long as your existing units are not modified, then the difference between strict and non-strict private is academic.
If your reasoning for the strict behavior is to use the compiler to help you refactor code that takes advantage of the less-private behavior, then adding the strict to one class at a time is a good incremental approach so you can get to a compilable and testable state more often. A whole sale change of behavior would require fixing every violation before you knew if any of them worked.
The reason private behaves like it does is similar to C++'s friend - it allows certain classes (or procedural code) to access private members. The VCL and RTL makes heavy use of this behavior, so a compiler switch or an all out change would break all of that code.
Delphi's implementation of private is private enough for all practical purposes since typically you control the unit your class is declared in. If you only ever declare one class per unit, and never include procedural code, then the difference is only academic.
I don't quite understand the question. But why would you need this feature? Why not just replace Privates in your code with Strict Privates if that is what you desire?
I expected your reason for wanting to change the meaning of private was that you wanted the stricter behavior without having to break backward compatibility. I figured you were producing a library that you wished to be usable with Delphi 7 and prior, which don't have the strict modifier.
But if that's not your reason, then I don't think you've got much to work with. You can convert all your private code to strict private pretty easily with a simple script.
perl -i.bak -pe 's/(?<!\bstrict )\b(private|protected)\b/strict $1/ig' *.pas
That takes any private or protected that isn't already strict and puts strict in front of it. It modifies the files in-place. (Beware; it may insert "strict" into string literals, too.)
So anyway, I don't think we're going to see private become strict anytime soon. Doing that could break old code, and there's not really much practical gain from it. It lets purists have "more pure" code, but they can already have that simply by using strict. I think that if we were ever going to have "default strict" visibility, then the time for the change was when strict was introduced in the first place. But as things are today, we already have a way of getting strict visibility specifiers, so there's no need for another change.