h a l f b a k e r yResults not typical.
add, search, annotate, link, view, overview, recent, by name, best, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Many object-oriented programming languages offer a "With" structure, which lets you quickly alter several properties of the same object. For example:
With MyPage.MyForm.TextBox1.Font
.bold = true
.italic = true
.size = 16
End With
But often you'd like to change the
same named property of several *different* objects, and so far I haven't seen a language with a statement that allows this. Here's what I'd like:
Concerning Font.bold
MyPage.MyForm.Textbox1. = True
MyPage.MyForm.Label1. = False
MyOtherPage.MyOtherForm.CommandButton1. = True
End Concerning
This would not speed up processing time, but it would make the syntax easier to read (for humans), and faster and less error-prone to type.
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., http://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
It's a good idea, but what happens when things fall out of the "Concerning" statement ? I guess this is why interfaces are such a big deal i.e. you can detect a bad cast to IBoldable. |
|
| |
The easiness is just a function of how many people buy into the concept of IBoldable or even IEasyStylable. Teamwork. The lack of it, the microsoft dictatorship of it or how you define it as a team. |
|
| |
Collection<IEasyStylable> myCtrls = new Collection<IEasyStylable>();
myCtrls.Add( MyPage.MyForm.Textbox1 );
myCtrls.Add( MyPage.MyForm.Label1 );
myCtrls.Add( MyOPage.MyOForm.CommandButton1 );
foreach ( IEasyStylable es in myCtrls )
es.Bold = F(es); |
|
| |
The interesting thing about this is is the function F() as its the only thing you really need to divorce your code from aspx. |
|
| |
pardon my mixing metaparticles but "bold" is an attribute, not an object: if you want to do what you want to do you have to associate it with an object and transfer the object's properties, ie: if it seems that important then start looking for an heretofore intangible object you may have missed somewhere along the line. |
|
| |
I think the more logical way to construct this is as a 'ubiquitous method' to any object within the current scope: |
|
| |
function ubiquitous boldit(state)
{
try {this.Font.bold = state;}
catch {return false;}
}
MyPage.MyForm. Textbox1.boldit(true);
MyPage.MyForm. Label1.boldit(false);
MyOtherPage.MyOtherForm. CommandButton1. boldit(true);
|
|
| |
//pardon my mixing metaparticles but "bold" is an attribute, not an object// |
|
| |
FT, an interface (in C# terms) defines the common attributes or methods of an object. It is sufficient to deal through the interface when associating with an object. |
|
| |
V^3, I used to think like that, but you miss out on so many compile time goodies. Which lets face it, is almost a necessity when working with the other retards. |
|
| |
[bs] you can do it in quite a few programming languages: I'm thinking a multiple "SET" type statement, but OO/C# no clue. |
|
| |
Or how about an intelligent "Bolding" agent to whom you can supply a list of object identifiers, and who's task is to spawn itself a new thread for each id which a child process will then use to go off and interrogate the identified object's classification for clues asserting its "boldability" (or any other pseudo-interfacial attribute you care to assign to this agent - which could be everything?!) on determining suitability, it will communicate with said object (using some predetermined protocol) instructing those objects to enbolden themselves appropriately. |
|
| |
The benefits of using this method is that you can distribute execution across multiple networks if you want - finally, a true process distributed type-setting engine!!! And about time too. |
|
| |
Can I ask a silly question? Yes. May I? |
|
| |
Is there a sort of meta-language that lets you write
sections of code in the most appropriate programming
language, something like: |
|
| |
LANG=C++
do this; do that; do something else; this bit written in C |
|
| |
LANG=FORTRAN
some cuneiform fortran |
|
| |
The reason I like the "Concerning Font.bold" statement is that, when reading the program, as soon as you see that, you know right away what that whole section does and whether you care about it or not. |
|
| |
I know I over-egged it, and others here have suggested the same thing, but I think just having some function (method, class, whatever your preferred language might call it) that "Does Bold" on a set of objects sent to it is the way forward - it's easy to see what it's doing (the actual boldy stuff happens somewhere outside of the main program-flow) and that's it. |
|
| |
Sure, you could create some clever in-language way to deal with that kind of thing, but isn't that what functions (methods, classes, etc) are for anyway? |
|
| |
//The reason I like the "Concerning Font.bold" statement is that, when reading the program, as soon as you see that, you know right away what that whole section does and whether you care about it or not.// |
|
| |
But what is boldworthy ? Is this actually a Concerning Titles or Concerning GeneralStyling ? |
|
| |
If only someone would hurry up and invent cascading style sheets. |
|
| |
[MB] some language compilers allow for inline code from other languages... obviously you'd need a compatible other-language compiler on hand. |
|
| |
In any case, if you are making so many individual changes to the boldaility of items, it is likely that you should be collecting them into some form of group and applying a general transform. However, if the boldality is an expression of logic (e.g. transmitting information other than style) then writing things out in the 'traditional' and non-concerning way would make more sense to me. |
|
| |
Then you are just left with the challenge of ensuring that screen-readers relate your boldality as you expect. |
|
| |
Actually, I'd look forward to some intriguing compiler error messages: |
|
| |
10538: There is no cause for Concern! |
|
| |
I'm sorry I can't buy into the one operationness of it. Code like that and you'll have endless blocks for adjusting other properties too. |
|
| |
Incidentally, you could extend the VB With syntax to do the set operations like in my second anno - |
|
| |
// highlight badly named controls
With ( MyPage.MyForm.Textbox1,
MyPage.MyForm.Label1
MyOPage.MyOForm.CommandButton1 )
.bold = true
.italic = true
End With |
|
| |
But I'm going to stick with interfaces as you can map them directly to style elements e.g. |
|
| |
public class TranslatableTitleLabel : Label, ITitle, ITranslatable {} |
|
| |
Then just be dragging one of those suckers onto your form, you've done all the work. |
|
| |
foreach ( Control c in myForm.Controls ) {
if (( c as ITitle) != null) myStyler.StyleTitle(c);
if (( c as ITranslatable) != null) myTranslator.Translate(c);
} |
|
| |
I'm not convinced that the With statement makes code any easier to read. Concerning might do slightly better though. A series of assignments on one object will line up on the screen, while a series of assignments on one property will not line up without odd formatting. |
|
| |
This is kind of the whole point of lambdas and similar access to functions as first-class objects. The problem you're addressing is an artifact of Java sucking, not a general problem. |
|
| |
lists:map(
fun (X) -> bold(X) end, [Form1, Form2, Form3]) |
|
| |
[form1, form2, form3].map { |x| x.bold = true } |
|
| |
map { $_->bold } ($form1, $form2, $form3) |
|
| |
Just use a language that isn't actively hostile to programmers. |
|
| |
…and her unfeasible shoe collection. |
|
| |