|
Trumpscript by samshadwell[^]
[...]
Features
Our language includes several convenient features, perfect for any aspiring Presidential candidate including:
- No floating point numbers, only integers. America never does anything halfway.
- All numbers must be strictly greater than 1 million. The small stuff is inconsequential to us.
- There are no import statements allowed. All code has to be home-grown and American made.
- Instead of True and False, we have fact and lie.
- Only the most popular English words, Trump's favorite words, and current politician names can be used as variable names.
- Error messages are mostly quotes directly taken from Trump himself.
- All programs must end with "America is great."
- Our language will automatically correct Forbes' $4.5B to $10B.
- In it's raw form, TrumpScript is not compatible with Windows, because Trump isn't the type of guy to believe in PC.
- The language is completely case insensitive.
[...]
I'd rather be phishing!
|
|
|
|
|
... a slightly regressed version of Ook[^] then?
|
|
|
|
|
Problem to solve:
every function call leads to indefinite loop or recursion generating spam messages about firewalls, intrusions and how great Carl Icahn is.
it ain’t broke, it doesn’t have enough features yet.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
I'm guessing it doesn't support imports.
|
|
|
|
|
and instead of overloading there's comb-overloading.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Any geographic boundaries where this script works? (It can catch IP addresses, right?)
On computing devices only in mainland US, Alaska, Hawaii, Puerto Rico. Where else? 
|
|
|
|
|
Doesn't compile on my machine. Says it doesn't like to compile to native.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
The lack of multiple inheritance. Instead of using collections in their native appearance, I like to create a class that inherits from a desired collection type, like so:
public class MyCollection : List<MyClass>
I do this because it allows me to write code specific to that collection, such as custom Add/Remove methods. In this case, I want to create a custom event that these collections send when something happens. Because there's no multiple inheritance, I can't simply write a little base class that implements the custom event code, because I'm already inheriting the List object. Instead, I have to duplicate the event code in every class from which I wish to implement it. Grrr...
I now return you to your government-mandated stupors.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 22-Jan-16 9:27am.
|
|
|
|
|
John Simmons / outlaw programmer wrote: The lack of multiple inheritance.
Yup. When you need it, you really need it, and interfaces are a pathetic replacement.
Marc
|
|
|
|
|
|
I updated my original message to provide an example.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I'd need to see the actual use case but maybe extension methods or (IoC like) function injection?
|
|
|
|
|
Duncan Edwards Jones wrote: When do you need it?
The use case that I've come up against in the past is the ability to extend a UI control's behavior to include some common behaviors. For example, what I want is:
class MySmartLabel : Label, CommonToAllControls {}
The idea being here that I can implement behaviors in CommonToAllControls and access them through the derived instance, and the instance can access methods in CommonToAllControls.
If I write it as an interface:
public class MyLabel : Label, ICommonToAllControls {}
I have to implement the interface functions in each class. At best, this means having stubby functions like void DoSomething() {commonality.DoSomething();} and, as you point out, use IoC to pass in an instance of ICommonToAllControls.
Or, I can invert it:
class CommonToAllControls
{
Control target;
}
But then I lose the ability to reference, without casting, the specific properties/methods of a control when I need them.
There are now other ways to skin the cat -- extension methods, for example.
Now, arguably, one might say that multiple inheritance is bad design because it fixes the implementation, whereas I might want to vary the implementation of CommonToAllControls. I can to a large extend agree with that, it's just that interfaces are a sort of klunky half-way solution to that problem.
Then again, maybe I've got some big gaping hole in my understanding of OOP!
Marc
|
|
|
|
|
In such case, extension method is definitively the best solution if you don't need events and properties...
Otherwise, I would use an interface and an helper class.
The less coupled the code is, the easier it will be to maintain.
Philippe Mori
|
|
|
|
|
In point of fact, more often than not interfaces simply aren't appropriate.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I'm glad I'm not the only one that thought that was a WTF thing to do in C#.
Jeremy Falcon
|
|
|
|
|
This wouldn't do?
class EventCollection<T> : List<T>
{
}
class MyCollection : EventCollection<MyClass>
{
}
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Oops, it took me too long to write my reply (see below)
|
|
|
|
|
Why yes, that would work. But I still want multiple inheritance.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I'm probably misinterpreting what it is that you want to do, but wouldn't something like this help?
public abstract class AbstractCollection<T> : List<T>
{
public delegate void OnItemAddedEventHandler(T item);
public event OnItemAddedEventHandler OnItemAdded;
public new void Add(T item)
{
if (OnItemAdded != null)
{
OnItemAdded(item);
}
base.Add(item);
}
public new void Remove(T item)
{
base.Remove(item);
}
public new void RemoveAt(int index)
{
base.RemoveAt(index);
}
}
The whole thing's rigged to blow, touch those tanks and "boooom"!
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Why not write a class with your custom event code which inherits the List object, and then inherit this class in MyCollection/whatever?
At least then you wouldn't have to duplicate the event code...
...or use the custom event code class as a Property in MyCollection?
(just some thoughts, of course it may not work this way for your purposes...)
|
|
|
|
|
List<T> probably isn't the class you want to inherit anyway.
Try Collection<T>[^] instead
|
|
|
|
|
|
No, I really do want List<t>.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
1) You can use extension methods.
2) For future maintenance purpose, almost always a better idea to use composition instead of multiple inheritance.
3) If the list is a private member of a class, then the custom method could be added to that class instead.
4) You can also use composition and have a property that returns the list if for example, your class purpose is to build a list.
In practice, you might loose a few minutes now but the application will usually be more maintainable if every class follow the SOLID principle.
When refactoring code, complex hierarchy are much harder to work with...
Philippe Mori
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
