Live data from Hacker News

What Can You Put in a Refrigerator?

prog21.dadgum.com

71–80 of 87 posts

Re: What Can You Put in a Refrigerator?

#71

The more I have to deal with corporate project management patterns, the more I think the whole approach behind specifications is wrong. Trying to focus on what the "domain objects" are and what is their flow is pointless, especially if you're dealing with real-world objects (like the fridge from TFA). You can model something this way, but it will be usually the imaginary perfect path, a narrow vision of how things sh…

That's where user stories can help:

"As a user, I want to store my food and drinks in the refrigerator so they don't spoil"

"As a user, I want to store drinks in the refrigerator so I can drink them cold"

"As a user, I want to store my medicine in the refrigerator so it can stay below 25 C"

Re: What Can You Put in a Refrigerator?

#72

Earlier quoted context omitted.

"Any contained item that can fit inside a refrigerator, whose quality would be better if kept at 1-4°C rather than at room temperature by the time it's used/consume."

I've definitely just placed a stalk of broccoli on the bottom shelf of my fridge with no container.

I would argue that the broccoli contains itself, or perhaps that the skin/surface of the broccoli is the container. (Though some people would argue that all vegetables in the fridge should at least be bagged, to prevent transfer of germs/grime.)

Re: What Can You Put in a Refrigerator?

#73
post #8
post #6

Earlier quoted context omitted.

Best before dates are a waste of time. I noticed this travelling in less devloped countries where they don't usually have them. And plenty of times I have had chicken that smells off despite being before the date on the packet. I had one cheese that got way better after being a month past the date.

Best before dates are a really good idea if you want to reduce the number of food poisonings in a large population. Food is (statistically) very safe before the best before date, assuming proper storage. Most of the time it's still safe well past that date, but you would dramatically increase the number of people who get sick. It's the same with pasteurized milk. Unpasteurized milk is mostly safe to drink, but occasi…

Best before dates have nothing to do with safety, they are about quality. They are (mostly) voluntary and set by the manufacturer.

http://www.webmd.com/a-to-z-guides/features/do-food-expirati...

Re: What Can You Put in a Refrigerator?

#74
post #70

Fun read. This reminds me of how "object-oriented" programming goes wrong for beginners. ...Not helped, alas, by all of the texts that thing it's helpful to demonstrate OO concepts by modeling things like "cat is a subclass of animal" :/

Not to derail too much, but.

I had a textbook that started to explain OOP by basically saying "A dog is a class. A dog has a tail that can be in a wagging state or not. A dog has a name..."

And I'm sitting there thinking "No, dog's don't 'have' names. We call them names and they respond to names. They sometimes know their name. It's a different kind of 'have' than having a tail. I have a name for my dog. Should the person class have a dogs_name member variable now?" A tail is a subset of a dog. A name is a property of the abstract system in which the dog resides.

A class is a model of something else. You can model a dog with an object, but you can't know how good of a model it is unless you dig down into it and see where it breaks down. It will break down, because software is an abstraction, and abstractions, being abstract, are not the things they are abstractions of. And there are not many things that behave like OO objects because they are far too simple to represent reality in any high-fidelity sense. And it's dishonest to pretend they do.

Not to say there isn't some pedagogical advantage to using the analogy, I just think a better one could be used. Like talking about messages or something.

Re: What Can You Put in a Refrigerator?

#75
post #66

Earlier quoted context omitted.

Can you put a baby or pet into a refrigerator? What about a freezer?

Well, it isn't the refrigerator that's going to stop you.

Yes! Things shouldn't prevent all the crazy that's out in the world... Users will try to find creative ways around requirements, being more graceful in handling the crazy is usually appreciated

Re: What Can You Put in a Refrigerator?

#76

"Any contained item that can fit inside a refrigerator, whose quality would degrade significantly more when kept at room temperature rather than at 1-4°C, by the estimated time of use/consumption." The term "contained" above is restrictive, and probably needs further precision. Only things that thrive inside an opaque and sealed container would fit the definition above. Otherwise, things that can affect the quality o…

Looks like you missed the point of the article. That spec is just as flawed as the other examples.

Re: What Can You Put in a Refrigerator?

#77
post #74
post #70

Fun read. This reminds me of how "object-oriented" programming goes wrong for beginners. ...Not helped, alas, by all of the texts that thing it's helpful to demonstrate OO concepts by modeling things like "cat is a subclass of animal" :/

Not to derail too much, but. I had a textbook that started to explain OOP by basically saying "A dog is a class. A dog has a tail that can be in a wagging state or not. A dog has a name..." And I'm sitting there thinking "No, dog's don't 'have' names. We call them names and they respond to names. They sometimes know their name. It's a different kind of 'have' than having a tail. I have a name for my dog. Should the p…

Hopefully it wasn't "POOP": http://www.amazon.com/gp/product/1878739441.

Re: What Can You Put in a Refrigerator?

#79
I'm going to repost something I had said in response to this article on another site. I think it's an awesome example of what can happen when you create a language with extensibility in mind.

-------------------

Scala solves this problem really well with typeclasses.

You can define a typeclass like

    case class Refrigerated[T](thing: T) // this is just something holding things that have been refrigerated. 
    trait Refrigeratable[T] { // this is the typeclass
      def refrigerate(thing: T): Refrigerated[T]
    }
Now we have a refrigerated object that holds some object that's been refrigerated, and it looks like I'm about to do some class composition, but I'm not. Bear with me.

Now, we have some sort of data class

    case class Pillow(fluffiness: Int, warmness: Int)
Pretty straight forward, we now have a Pillow with measurable fluffiness and warmth

Next, lets implement refrigerated for pillow.

    implicit val pillowRefrigerable: Refrigerable[Pillow] = new Refrigerable[Pillow] {
      def refrigerate(pillow: Pillow): Refrigerated[T] = 
        Refrigerated(pillow.copy(warmness = pillow.warmness / 2))
    }
So there's an implementation of Refrigerable for pillow. Refrigerating a pillow just cuts the warmness in half.

So actually using the Refrigerable stuff. There's two ways to go about this. One way is to just use the Refrigerable instance to refrigerate the pillow.

    def refrigeratePillow(pillow: Pillow): Refrigerated[Pillow] = pillowRefrigerable.refrigerate(pillow)
Nothing special there. You could basically do that in any language. So how does scala do it better? Well, we can define a refrigerate method for anything Refrigerable like this:

    def refrigerate[T](thing: T)(implicit refrigerableInstance: Refrigerable[T]): Refrigerated[T] = 
      refrigerableInstance.refrigerate(thing)
Now this is really cool. Anything type that we have a Refrigerable instance for, can be used as an argument for refrigerate. And we don't have to explicitly state what Refrigerable instance we're using. Calling it looks like

    val refrigeratedThing = refrigerate(anythingWithARefrigerableInstanceHere)
Okay. We still haven't gained a whole lot. All we've done so far, is make it so we don't have to explicitly state what Refrigerable to use. So let's go an extra step. Let's make it so we just call refrigerate on the Object itself rather than passing the object as an argument to a method. This is possible, because scala let's us make extension methods for generics.

    implicit class RefrigerableOps[T](thing: T)(implicit refrigerableInstance: Refrigerable[T]) {
      def refrigerate: Refrigerated[T] = refrigerableInstance.refrigerate(thing)
    }
Okay, now this is really cool. We've defined a method for any type for which we have Refrigerable in scope. This means we can now refrigerate our pillow more easily:

    val refrigeratedPillow = myPillow.refrigerate
What?! That's great! And it gets better. Now that we've implemented this boilerplate, giving other things this wonderful syntax is easy. Let's say I want to refrigerate my cousin, because she's too hot.

    case class Cousin(hotness: Int)
    implicit val refrigerableCousin: Refrigerable[Cousin] = new Refrigerable[Cousin] {
      def refrigerate(cousin: Cousin) = 
        Refrigerated(cousin.copy(hotness = cousin.hotness - 1))
    }
Now we can make our cousin less hot! Great!

    val refrigeratedCousin = cousin.refrigerate

This is basically a good way to make things open to extension without subclassing it's awesome!

You can even do more to simplify making the Refrigerable instances. You can effectively make them one liners.

Post reply on HN