Senior Software Developer
|
| 2 people marked this as a favorite. |
It's a puzzle about Loafs, and what they can become. I am reasonably confident there is an answer, however, I don't know what it is. Yet.
Meet the Loafs. There are seven kinds:
OExpandingLoaf has three children: OPartialLoaf, RegionLoaf and OVirtualLoaf. InnerLoaf, sibling of OExpandingLoaf, has two children: SplitLoaf and DspLoaf. We shall speak no further about DspLoaf.
Some types of Loafs can "become" a different kind of Loaf when asked politely.
An OPartialLoaf can become either a RegionLoaf or a SplitLoaf. So can an OVirtualLoaf. And a RegionLoaf can become a SplitLoaf.
Apparently this worked well in the distant past. However, the world has changed:
The ability to "become" something else is an extraordinary ability, which no longer functions. That's OK, it was an expensive and time-consuming thing to do anyway. A replacement is needed.
Let's call it a LoafWrapper. Its job is to pretend that it's a Loaf that can "become" other kinds of Loafs. It does this by keeping a private Loaf no one else can see. When asked to do anything, it lets the private Loaf do all the work. (And get none of the credit!) When asked to become some other kind of Loaf, it gets a new private Loaf of the requested type, and unceremoniously dumps the old private Loaf onto the garbage heap. LoafWrapper's kind of a jerk, I suppose.
Here's the problem: The Loafs that can become a SplitLoaf (OPartialLoaf, OVirtualLoaf and RegionLoaf) are actually cousins of SplitLoaf instead of siblings. If LoafWrapper is a member of the RegionLoaf family, then it can't pretend to be a SplitLoaf -- they're not directly related.
What family should LoafWrapper be a part of?
For extra difficulty: In general, Loafs are Loafs, no matter what kind they really are. However, there are three exceptions. A BePlaceHolder (distant relative of the Loaf family) sometimes refers to a Loaf as a RegionLoaf. And SplitLoaf and DspLoaf occasionally refer to Loafs specifically as InnerLoafs. (OK, we did speak further about DspLoaf. But no more.)
(?!?)
You're a strange little man...
Ultradan
I'm fairly certain that you can get medication for this.
(Or maybe you already did...)
| 1 person marked this as a favorite. |
Meet the Loafs...
Oh, I get it... Meatloafs!
lol
Ultradan
|
Senior Software Developer
|
There are, of course, any number of ways to solve the Loaf question. Perhaps the LoafWrapper is inherently impossible. (I don't think so, but haven't determined whether it is yet. I'm lazy like that.)
So introduce a notification center. If you have a Loaf which might become another kind of Loaf, you tell the notification center you'd like to be notified when your Loaf becomes something else.
A Loaf, when asked to become another kind of Loaf, would then post a notification saying, "I was this Loaf, but now I'm this other Loaf." The notification center then informs everyone who was interested in that particular Loaf about the change. In response, you switch your reference to the original Loaf to the new Loaf.
This would work, but I don't think it's scalable. There are probably going to be millions of Loafs, and who knows if the notification center can handle that kind of burden?
(Now, given that the Loafs are part of the Ent, perhaps the notification center would be built using an Ent! Then it would be scalable, but in a weird way that makes my head spin.)
Ah. A new term. The Ent. A walking tree of long memory.
STOP MESSING WITH OUR MINDS!!!
U.
|
Senior Software Developer
|
A BePlaceHolder may ask a RegionLoaf to forward itself to a BeRangeElement. So far so good. RegionLoafs know how to do this.
But a RegionLoaf (a kind of OExpandingLoaf) can become a SplitLoaf (a kind of InnerLoaf). And SplitLoafs know nothing of forwarding.
Perhaps it would be best to teach SplitLoafs how to forward.
Bella Sara Charter Superscriber
|
I am a lawyer.
You are wrong.
(sorry, that's my one and only trick. You would think on a D&D board there would be at least one other person, possibly even someone using the screen name Lilith, with some sort of relevant ability to comprehend techno-speak. However, I am absolutely positively not that person.)
P.S. It really sounds like a family court matter to me.
|
Director of Sales
|
| 3 people marked this as a favorite. |
Pfft...
This is so simple.
You just need to create a new Loaf, we'll call it CryptoLoaf.
CryptoLoaf is not in fact a Loaf at all, but a series of discreet appellations. Let's call these appellations "Slices". When arranged sequentially, the Slices form a CryptoLoaf that can spoof the "O" family Loaves into seeing it as a SplitLoaf, while still appearing as a spooler to the DspLoaf.
You just need to create two user masks for the Slices to use. Let's call one "Mayo" and the other "Mustard". You compile two slices with the matching user masks talking to one another using the shared language "Bologna", and you have yourself a nice little meal.
This kind of thing always requires a LOT of Bologna.
I call your bluff, postmonster.
| 1 person marked this as a favorite. |
Poor DSPLoaf...he's the black sheep, the cousin no one likes to talk about...
Maybe LoafWrapper needs to have a few drinks with RegionLoaf, do a little romancing and start a Family of their own. (Private Loaf is a good soldier, but since he's enlisted, will regularly be trod upon by his commander, LoafWrapper.) I think LoafWrapper needs to be a member of RegionLoaf's family - don't they make a cute couple? :)
NotifyCenter looks good on paper - Ent is difficult to work with, but doable if you water and feed him nicely.
By the way, this question has been bugging me all day. I keep wondering what did poor DspLoaf do...
|
Senior Software Developer
|
I believe Cosmo may be onto something!
No, wait. Scratch that. Let us speak of Crums and OParts.
Loafs are actually a kind of OPart. So are OrglRoots, of which there are two kinds, EmptyOrglRoot and ActualOrglRoot.
And then there are the Crums. There are two main families of Crums, the HistoryCrums and the CanopyCrums.
HBottomCrum and HUpperCrum are HistoryCrums.
BertCrum and SensorCrum make up the CanopyCrum family.
Each CanopyCrum has one parent CanopyCrum and two child CanopyCrums (creatively referred to as "parent", "child1" and "child2").
All OParts have a SensorCrum. All OrglRoots have an HBottomCrum.
HistoryCrums have a BertCrum.
|
Senior Software Developer
|
A possible solution!
Loafs are OParts, which in turn are a type of Abraham. Abrahams are a kind of Heaper. We want to be able to turn one kind of Loaf into a different kind, but can't because they're not closely related.
(Ah. More new terms. Abraham: shepherd for a flock, which are packed into Snarfs. Heaper: something kept on a heap. I believe Abrahams and Heapers may eventually go away.)
So. Make Loaf an agreement to behave a certain way, rather than an actual thing. To do this, we need to do the same to OPart, Abraham and Heaper. They are no longer things, but instead just agreements to do certain things certain ways.
To get this to work, every kind of Heaper is now a kind of ActualHeaper. ActualHeaper promises to do everything a Heaper does, so we're good. We do the same with the various types of Abrahams. They all are now types of ActualAbrahams instead of Abraham, but since ActualAbraham promises to do whatever an Abraham does, we're good. And we do this again for OParts. They're now ActualOparts.
Now we can actually get started with the whole Loaf thing. First thing we do, turn Loaf into another one of those agreements. But instead of ActualLoaf, we make a new thing called WrappedLoaf, which promises to behave just like a Loaf. And InnerLoaf and OExpandingLoaf are now members of the happy WrappedLoaf family.
A WrappedLoaf keeps its own private Loaf to do its bidding. When asked to "become" some other kind of Loaf, it'll dump the old Loaf and replace it with the new one. This has not yet been done.
|
Director of Game Development
|
I'm so tempted to get my non-gamer programmer on this thread, but I'm not sure he'll get it. That's only because I don't quite get it and think he might despite all the metaphors. And we're quite busy right now and he already wrote an app this week.
Whatever in the nine hells you're talking about, if it'll make these boards run faster and smoother then I'm willing to distract him for a bit.
|
Senior Software Developer
|
Prequel: Those Which Need Removal
Before The Loaf Question can be dealt with, there are many things which must be removed. They are, variously, unnecessary, unneeded, unwanted, uncouth, untried, untested or destined to be replaced. More will certainly be removed in the future. So far, the toll includes:
CacheManager, InstanceCache, SuspendedHeaper. We need them not.
PrintCBlocksTracks, TrackCBlocks. They are dead to us.
Butterfly, Chameleon, DeadMoth, GoldButterfly, IronButterfly, LeadButterfly, Moth, DeadButterfly. Short-lived, to be sure. They become, but not what we need them to be.
BHHandler, BHHHandler, BHHHHandler, ExampleHIHHandler, ExecutePromiseFile, HHandler, HHBHandler, HHHandler, HHHBHandler, HHHHandler, HHHHHandler, HHHHHHandler, HHHHHHHandler, HHHHHHHHandler, PairPortal, SpecialHandler, VHBHandler, VHHandler, VHHHandler, VHHHHandler, VHHHHHandler, VHHHHHHandler. Why, gods, why?
BecomeTester. Because.
ActualCategoryTable, CategoryTable, Converter. RIP.
ActualCalc, BertPropJoint, BooleanVar, Calc, FeCompletionDetector, FeFillInDetector, HRoot, IntegerVar, IObject, MuWordArray, OccludingCategoryTable, PackageCategory, PackOBits, PropJoint (please do not bogart), SensorPropJoint, SequenceDsp, Signal, SocketPortal, SplayEntLoaf, Stamp, TransclusionRecorder, TwoStepper, XnSensor, XuRegion, EntView, InspectorView, Stream. Failed experiments or vestiges, one and all.
On the list: Recipes. Categories. Thunks. Fluids. Emulsions. Oh yes. Fluids and Emulsions might be next.
This isn't happening...
...
This isn't happening...
...
This isn't happening...
...
Ultradan
| 1 person marked this as a favorite. |
*snip*
Mass GENOCIDE of Code
*snip*
ROFL!
Vestiges! That's what happens to old code! And here I thought they went to the Great Bit Bucket in the Sky! They come back to haunt you in the Repository of That Which Must Not Be Spoken and sneak into the Code Which Must Be Tested.
|
Ah the joys of coding...
If one could assume that Loaf is or was depending on where in the conversation you interject this, the parent of the siblings OExpandingLoaf and InnerLoaf, AND one can make the paradigm shift toward the agreement (and away from the actual) then make the Loaf an agreement. If the LoafWrapper abides by the Loaf agreement, then it can become the parent. Now evey Loaf is secretly a LoafWrapper (although they need not know it).
It seems odd that a particular Loaf secretly holds a private Loaf that may or may not be itself (since it can become a different Loaf, that being held in secret) but I do this kind of debauchery all the time and I haven't gone blind.
So to answer your original question, the LoafWrapper should be the one to rule them all!
Yes?
|
|
...It seems odd that a particular Loaf secretly holds a private Loaf that may or may not be itself (since it can become a different Loaf, that being held in secret) but I do this kind of debauchery all the time and I haven't gone blind....
Upon further reflection, it must be that your LoafWrapper's secret Loaf be allowed to be nil, null, and void.
Ideally, you would want to intorduce LoafWrapper as a partial agreement. Whilst fully a Loaf, all the loafy goodness would be handled by it's particular self. Only when the secret Loaf is not nothing would it be called on to do the work. Then all is well in land of Loaf.
|
|
A possible solution!
...
Now we can actually get started with the whole Loaf thing. First thing we do, turn Loaf into another one of those agreements. But instead of ActualLoaf, we make a new thing called WrappedLoaf, which promises to behave just like a Loaf. And InnerLoaf and OExpandingLoaf are now members of the happy WrappedLoaf family.
...
Ee gads! I didn't read the post closely enough to see you were already on it - you are developer par excellence!
|
Senior Software Developer
|
The wrapping of Loafs is complete. All Loafs now agree to respond to all Loafish requests. Individual members of the family reserve the right to complain if asked to do something which only their cousins would do. This decision may need to be revisited.
Let us now turn to Recorders, TrailBlazers and Fossils.
Recorders are like the answer to a question, but the answer is never complete. It hangs there in the canopy, continually responding as the Ent grows and changes. A Recorder uses a TrailBlazer to actually record its trail of answers. Legend implies that a Recorder may be saved permanently as a Fossil.
A typically misleading quote from the literature:
A Fossil (unlike a Grabber or an Orgl) does not prevent the grabbed IObject from being dismantled. Instead, if the IObject does get dismantled, then the Fossil is considered extinct. A waldo may not be gotten from an extinct fossil (if the species is really extinct, then it cannot be revived from its remaining fossils).
This is misleading because there are no such things as Grabbers, Orgls or IObjects. The Waldo is an entirely imaginary creature. These are myths, fairy tales, ancient legends, whose purpose has been lost to the distant past.
Should the Fossil join these imaginary creatures on the dustbin of history? Or is that too dramatic? The Fossil family is small (only seven clans) but widespread.
And there's something called the "delayed store backfollow" of which the Fossil is a key part. (The literature says: "Do the northward H-tree walk for the 'now' part of a backfollow." Yes. That sounds like a good idea.)
I was interested enough in reading the first post here to inquire with one of my good friends, a college instructor of mathmatics and computer science here in STL, as to the general drift of the poster's problem. Here is his response:
"In an approach to programming called Object Oriented Programming the designer builds a hierarchy of smaller programs, called objects, which work together elegantly to solve the problem. Each object contains certain elements--variables and functions--as well as an interface to let other objects access these elements. The idea is to design the hierarchy so that the interaction among the objects solves the problem optimally.
For example, a microwave oven could be an object. The electronics inside would be its variables and the operations of Heat, Thaw, etc, would be the functions. The panel on the front where you type in the numbers would be the interface.
This is slick design because, if you want to upgrade a microwave, you can keep the interface the same and improve the innards without having to retrain everything that needs to interface with the microwave.
In programming, you might write an object called Account to deal with banking accounts of some kind. Its elements would be things like Balance, Min Balance, Avg Monthy Balance, Interest Rate, etc, and its functions would include Deposit, Withdraw, and Transfer.
Now, if you have lots of accounts to manage the efficient way to do this is to structure the hierarchy such that the Account object is the parent of child objects such as Checking and Savings. These children would then inherit all the functionality of the generic account and you would only need to do additional programming for the things that make them special. For Checking, you would add Check Numbers and Stop Payment options, for example.
As you design more complicated software--say the Windows operating system--this need for intelligent organization magnifies exponentially.
The things OLoaf, etc, that the poster mentions are all objects that do something. Exactly what is not important for the question. The riddle is how best to organize them given certain constraints.
One poster proposed an interesting solution, but it's a hack and very inelegant. His third post is a little more efficient, but I think more reorganization of the objects would be beneficial. But, thinking about it is way too much work. I have my own programming issues to deal with!
So, there you go. Introduction to Object Oriented Programming 101."
Hope this helps those with enough knowledge of programming to make suggestions, and at least the rest of us can now conceptualize the problematic.
As ever,
ACE
Criminy, Gary!
Here's some love
|
Senior Software Developer
|
Last night I got this contraption running. At least I think it's running. Hard to be sure when you see stuff like this:
After endorsing:
on Edition: {{0!-1 | 0!666.42.[16, 17)} x {0!-1 | 0!666.42.[16, 17)}}
on Work: {{0!-1 | 0!666.42.[16, 17)} x {0!-1 | 0!666.42.[40, 41)}}
After unendorsing:
on Edition: {}
on Work: {}
The trail is: Edition([0, 1) -> Work(ids: {0!-1 |} contents: Edition([0, 12) -> Howdy doody.)), [1, 2) -> Work(ids: {0!-1 |} contents: Edition([0, 8) -> Good bye)), [2, 3) -> Work(ids: {0!-1 |} contents: Edition([0, 12) -> Much better.)))
I(0)->Howdy doody.
I(1)->Good bye
I(2)->Much better.
From what I can tell, it's doing what it's supposed to. I think.
And to think that none of this loafing would exist or matter forty years ago. My how the world changes so quickly.
Good job. I'm glad it's performing. Are you gonna eat the crust? Oh wait! YOU DID ACCOUNT FOR CRUST, DIDN'T YOU?!"
::dives for cover::
|
Senior Software Developer
|
And to think that none of this loafing would exist or matter forty years ago.
Ah, but there's where you're wrong. This is a project that got started more than forty years ago. This is serious vaporware.
YOU DID ACCOUNT FOR CRUST, DIDN'T YOU?!"
::dives for cover::
We have two separate canopies over the Ent, is that good enough?
|
Senior Software Developer
|
Criminy, Gary!
Here's some love
You just like that book because it was named after you. :-)